Tim Cook has been Apple's CEO for 15 years, one year more than Steve Jobs. His name is so synonymous with the company that the President of the United States referred to him as Tim Apple and it stuck. Neither Steve Jobs nor Steve Wozniak was ever known as Steve Apple, which is really saying something. But those days are done now as Tim moves on from Apple and becomes Tim Retired. Will John Ternus serve for even longer and also change his last name? Be sure to open Flight Deck #239 in 2041 to find out.
Whether you’re known by your own last name or are so synonymous with your company that the company name becomes your surname, like you’re one of its parents (or it's one of yours), the Flight Deck will be here pondering the economics of software teams, small SwiftUI warnings and the long journeys to understand them, and whether you should build or buy your mobile release tooling.
Posts we liked
Apple’s Cook leaves Ternus a pipeline of 10 major new product categories
Very generous of Tim to leave John with such an expanded pipeline. This most notably includes Apple’s new folding phone, the iPhone Ultra, which was designed by John and his team. Not since Steve Jobs launched the original iMac in 1998 have an Apple CEO’s fortunes been so closely tied to a new product line. It’d be like if Tim Cook (who famously ran supply chain logistics) unveiled a new line of cargo ships to go back and forth to Shenzhen as his first move as CEO.
The economics of software teams and why most organizations are flying blind
Do you know how much that new feature costs your team compared to the value it delivers? You know, that one you spent six months working on and that 4% of your users are using. On average, a software engineer makes ~$150,000 a year (or ~130,000 Euro). There is some wiggle room, and engineering salaries may be higher or lower in different parts of the world and for different responsibilities, but Viktor Cessan looks at how we can use this number as a starting point for calculating the economics of an engineering team and the costs of the features we all build, expand, and maintain.
The future of Android apps with AppFunctions
More and more (and even more) people are using LLMs to answer questions and search for things. Even when they still use Google Search, more often than not, the first thing they see and engage with is Gemini’s attempt at an answer whose accuracy is known to vary. If LLMs cannot see the functionality of your app on a user’s device, they may not even know it exists, let alone tell people about it and enable them to use it. Shreyas Patil dives into how AppFunctions fix this by letting you create self-describing functions that LLMs can see, read, and describe to people who ask.
Probabilistic engineering and the 24-7 employee
When the steam engine was first invented, it was so inefficient that the only practical use case for it was in coal mines, since that was the only place with enough coal around to power it. As the steam engine became more efficient and required less coal, this somewhat paradoxically led to the need for even more coal as people found more and more ways to use these better and better steam engines. What does this have to do with anything? Well, change the last two letters in coal to “de” and you get code. As code gets cheaper and easier to create, we are likely to need even more of it to meet the need for its expanded use, and more people who can guide how it's put to use. Tim Davis looks at where this is likely to go.
A small SwiftUI warning and a long journey to understand it
Where does a warning or bug come from? And why did the fix you implemented fix it? Is it actually the right fix, or is it also not quite right (just less not-quite-right than the cause of the bug) and is likely to cause some other problem somewhere else down the line? Even if a fix is a small change to a line of code, taking the time to truly understand why it works — versus, why something else doesn’t — can lead to better decisions in the future. Alejandro Martinez takes us on a philosophical journey into a warning he fixed.
AI productivity gains: more modest than expected
The average engineering org has seen usage of AI tools increase by 65% while PR throughput has increased by only 8%. Any increase in throughput is helpful, but this hardly matches claims that AI is on the verge of replacing all software engineers or relegating every knowledge worker to floating Wall-E style floating couches where we do nothing but down soft drinks and watch TikToks. Why the disconnect? Brian Nouck takes a deep dive with Abi Noda into DX’s longitudinal study on AI’s impact on engineering velocity.
Go figure
As this new age of vibe coding descends upon the world, Apple has already seen an 86% increase in the number of new apps submitted to the App Store in Q1 of this year.
How many new apps were submitted in Q1? 235,800. That’s 2,690 per day. 112 per hour. 2 per minute.
To better manage this influx, Apple now requires new developers to share (among other things) a screen recording captured on a physical device demonstrating their app's functionality and a description of the app's purpose, including the problem it solves and the value it provides. This growth in new app submissions has caused Apple’s review times to balloon from plus or minus 24 hours to up to as much as 30 days. The App Store is flooded with AI slop and legitimate developers are paying for it.
Posts we wrote and live panels we're hosting
Build vs. Buy: Mobile release tooling
Should you build or buy when it comes to mobile release tooling? Engineers from teams that have built, bought, rebuilt, and rebought (not necessarily in that order) share how they made the call. Register to join our panel on May 28th at 1pm ET and dive into the firsthand experiences of Maria Neumayer from Monzo, Jacob Vesterlund from Spotify, Jay Henry from Etsy, and Pedro Piñera from Tuist. We'll talk through how they evaluated the decision, what the real costs look like, how to know when what you've built is no longer working, and how AI changes the calculus.
How to improve visibility and coordination across your mobile release process
You can boost visibility and coordination in your mobile release process by creating a single source of truth for release status, defining clear ownership at each stage, automating routine handoffs and notifications, and defining health metrics and standards for everyone on the team to operate based on. The biggest lever is moving from scattered, tribal knowledge driven releases towards a structured and self-documenting process. This way, every stakeholder can see exactly where things stand without needing to ask and rules of engagement are clear. This all sounds pretty obvious. So why is it so hard for mobile teams to actually get there?
Runway featured feature
Are you a retail app heading into Black Friday or a sports app heading into the NBA Finals? Instead of needing to manually disable your release schedule and related automations (e.g., auto-kickoff, submit, and release) in Runway and remember to re-enable them, you can configure “lifecycle freezes” that will automatically put your train on pause during selected dates.
Once outside the window, Runway will either resume the in-progress release or kick off a new one based on your schedule. Just one of many ways that Runway keeps you keep your release train on time.
Events
WWDC is around the corner, and so too is the third annual Runway Apple Park Happy Hour at the Duke of Edinburgh, directly across the street from the Apple Mothership.
Over the past two years, we’ve all wondered whether Woz drinks and/or eats at the Duke. So far, we’ve not seen him, but the third time’s the charm. Or maybe Tim Apple heads there now with all his newfound free time?
If you’re not going to be at WWDC, we have more events and happy hours to come. We’ll announce them in future editions of The Flight Deck, just as we did in our previous 31 installments.
