It’s a common cry whenever there are problems with a macOS update: why doesn’t Apple revert to a slower development cycle so system updates are less frequent and more reliable? My answer is that Apple has generally had short cycles, and if anything its recent updates have been more reliable than they used to be. Claiming otherwise is imagining a past that never existed. Let me explain.
Classic Mac OS
There are many problems in trying to make comparisons with releases of Classic Mac OS. Not least is the fact that all the earlier releases were on floppy disks, which had to be duplicated by the thousand for distribution. Apple’s version numbering also confuses: although the first of the three numbers was designated as the ‘major’ release, many of the ‘minor’ releases were every bit as major. For example, in System 8, 8.1 brought the HFS+ file system, and 8.6 brought a new nanokernel which supported multitasking. In Mac OS X, either of those would surely have warranted a ‘major’ release, there marked by an increment not in the first version number, but in the second, as in 10.3 to 10.4.
Another good example is System 7.5, released in September 1994. It was followed by a large collection of bug fixes in 7.5.1, then 7.5.2 introduced Open Transport networking, 7.5.3 another series of bug fixes, which even went into 7.5.3 Release 2 (the equivalent of a Supplemental Update today). It successor, 7.5.4 was such a disaster that Apple had to withdraw it when much of it wasn’t even installed properly. Next, 7.5.5 introduced major changes in memory management and elimination of a troublesome type of error.
By my reckoning, between System 5.0 in October 1987 and the first release version of Mac OS X in March 2001, Apple released ten major versions of Classic Mac OS. Of the 11 intervals between them, eight were less than 18 months, and from System 8.0 to Mac OS X the longest interval was only 15 months (9.0 to 9.1). It’s also worth noting that System 6.0 was released just six months after 5.0.
Mac OS X
Once Apple had released the first non-beta version of Mac OS X in March 2001, new releases continued apace. Of the 15 release cycles before macOS 11, only 4 were 18 months or longer, from 10.3 to 10.7, and only one (10.4 to 10.5) was two years or longer.
Mac OS X 10.4 Tiger not only had the longest cycle of them all, but the most updates. As it spanned the transition from PowerPC to Intel processors, updates from 10.4.5 onwards were separated by processor too. The last version of Tiger reached version 10.4.11, which shipped nearly three weeks after the release of the first version of Mac OS X 10.5 Leopard.
Before the introduction of System Integrity Protection, installing an update had become quite a chore too. The only file system, HFS+, has remained notoriously liable to develop silent minor errors which could readily bring disaster when installing an update. Wise Mac users therefore followed a sequence of:
- Check and repair the startup disk using Disk Utility, or DiskWarrior.
- Install the update.
- Check and repair the startup disk again.
- Repair permissions on the newly-installed system.
Even following this time-consuming ritual, it wasn’t unusual for installations or updates to go wildly wrong. This started to change with El Capitan in 2015, when System Integrity Protection (SIP) prevented third-party installers and apps from meddling with system files. The common practice of repairing system file permissions ceased with the adoption of El Capitan, which has been a great relief to users for whom it had become a panacea.
Inevitably, not every system installation or update works properly. With tens of millions of macOS users, even tiny failure rates result in thousands of Macs being affected. So when you see a few users complaining that an update didn’t work properly, don’t be surprised in the least.
Currently, in macOS Catalina, although the System volume is now separated from the writable Data volume, read only, and protected by SIP, its integrity isn’t yet verified rigorously. One of the major advances with Big Sur is its new Sealed System Volume: this checks a hierarchy of cryptographic hashes for the entire System volume to ensure that it matches that set by Apple. If the Seal doesn’t match, then that copy of the system – now a mounted snapshot anyway – isn’t used. This provides a perfect integrity check, and guarantees that the installed system hasn’t been corrupted or misinstalled in any way.
I’m sure that Apple and every Mac user wants to see the quality of updates and upgrades improved. Doubling the length of the development cycle is an appealing approach, but would it achieve anything? At present, a quarter of every year is occupied by developer and public beta-testing of the next major release of macOS. It’s that beta-testing which is most critical for discovering bugs in bundled apps and major features such as Time Machine.
In a two-year cycle, the same proportion of the cycle could be devoted to beta-testing by extending that phase to six months, of course. However, that’s most unlikely to result in twice the amount of testing and bug-fixing which is currently accomplished in three months. Although it would give third-party developers longer to work with the new macOS, a longer period also reduces the pressure on testing, and the big danger is that it would become much less intense and intensive, so allowing more bugs to pass unreported.
Surely the most important way to improve quality is to strengthen quality management processes throughout engineering – the principle of building it right first time, rather than expending more effort at detecting and remediating errors. Simply extending the cycle without changing quality management would be very unlikely to result in any improvement. But better quality management doesn’t entail making the cycle any longer, so cycle length is unlikely to be relevant, as was shown by Apple’s only real two-year development cycle with Mac OS X 10.4 Tiger.