This past weekend, Mark Gurman at Bloomberg reported that iOS 27 will be a “no-frills ‘Snow Leopard’ update” focused on “quality improvements and artificial intelligence features.” If you remember the Mac OS X Snow Leopard release with fondness, as I do, you’ll be tempted to see this as the solution to the software quality issues in Apple’s operating systems.
Snow Leopard holds a special place in the memory of Mac fans and admins—a quality-focused release after years of feature-heavy releases, especially Mac OS X Leopard and its “over 300 new features.” But it also gave birth to a premise in the collective consciousness of the Apple community: the only way to introduce quality into a software product is to take time away from features. In the case of Apple’s annual operating system releases, this means taking “a Snow Leopard year.” Many have clamored for this and they might now be getting their wish.
But the year after Snow Leopard shipped, Jez Humble1 and David Farley published Continuous Delivery. In it, they demonstrated techniques that software developers were already using to build quality in while shipping features. “Shifting left”, as it became known, moved the quality and testing phases of software development to occur in near real-time as the features were written. Put another way, the idea that one has to trade feature work to get quality in software is a false dichotomy.
Rather than a singular year focused on quality, Apple needs to adopt such software development methodologies, especially but not limited to comprehensive automated testing, early in their development process. This will lead to quality releases year after year. I am not excited about a Snow Leopard-style release in 2026 because it implies two things that aren’t admirable: 1) that we go back feature releases without a quality-focus in 20272; and 2) that Apple’s software development methodologies haven’t leveled-up to the state of the art from 2010.
Without arguing over the semantics of these methodologies, what is irrefutable is that on an annual basis, Apple distributes beta operating systems in June, which are unreleasable, and then focuses on quality from then until shipping them in September. It is this approach, one that attempts to add quality late in the process, that is the root cause of Apple’s software quality issues.
The Next CEO3
The above news comes a week after it was likely leaked to the Financial Times that Apple has moved up succession plans for CEO Tim Cook’s retirement. Tim Cook doesn’t have the background or interest in software engineering or its methodologies. That’s understandable. The article states that current SVP of hardware engineering, John Ternus, is the leading candidate to replace Cook.
Ternus appears excellent in his current role. You can count the number of Apple hardware design issues from the last five years on one hand, and none of them are fatal flaws. I hear nothing but excitement at the notion of a “product person” running Apple. But in the context of the software quality, I’m suddenly excited at the notion of an engineer at the helm of Apple. (Ternus holds a bachelors in Mechanical Engineering.4) Here is someone who understands the discipline it takes to engineer and ship a quality product.
But regardless of who it is, the next Apple CEO needs to appoint someone who will lead the software engineering division to the quality heights that Ternus has led the hardware engineering division to.
Having a quality-focused release once every seventeen years isn’t adequate. As Humble and Farley showed fifteen years ago, software releases can be both feature-rich and low-risk. It’s well past time that Apple caught up.
- Jez has been my guru on this subject. In addition to reading the book, I’ve taken his course. I strongly suggest watching this keynote as a primer on the topic. ↩︎
- I don’t hear people remembering OS X Lion so fondly. ↩︎
- Alternative heading: ‘Can they Ternus around?’ ↩︎
- https://www.apple.com/leadership/john-ternus/ ↩︎
Appendix: A Keychain Access bug
To demonstrate how testing helps even at a small scale, here’s an example of a regression in macOS 15’s Keychain Access app. It’s fixed in macOS 26.0. In short, Keychain Access shows no entries in its main table view. It looks like data loss, but thankfully it isn’t.
How does a comprehensive (or even minimal) test suite help here? During macOS 15’s development, a change was made that caused this bug. Had there been a most basic test run soon after, the bug would have been identified and the developer would have to either back their change out or fix the failing test before their change would be allowed to be integrated into the main line build of macOS 15.
It isn’t a hard test to write. Another of Continuous Delivery’s tenets is that tests should own their data—in this case, one or more Keychains. If the test keychain data has 22 items in it, we’d expect 22 rows in the application’s main table view. If we get any other number of rows in the table view, the test would fail. From there, one could test other functions, like searching for known items.
Keychain Access is a part of macOS that won’t and shouldn’t get developer attention every day. It’s unlikely to receive bug reports from end-users. But it can get tested by a computer daily or weekly. Had it been properly tested, this little bug wouldn’t have crept into the app for a year. Now, imagine how this technique would improve software quality when used across the whole OS.
macadmin.fraserhess.com 
Leave a comment