hoakley September 30, 2020 Macs, Technology

Were Apple’s system updates less frequent and more reliable?

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.

Improving quality

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.

12Comments

Add yours

1

EcleX on September 30, 2020 at 7:01 am

Thanks. Wise words, in general, to which I agree. Whatever the reason, Apple should address this serious problem. Computers (both software and hardware) are becoming more and more complex, which increases the probability of issues. It is as with living beings; the more complex they are, the more likely to also get complex diseases, like brain-related ones in humans versus worms, for instance.

On the other hand, as said elsewhere, if a device is bricked due to an Apple update installation (whatever it is, beta or final, security or whatever), Apple should warn about such dangers, pay the required repair or replacement in full, free of charge for the user, including shipping, if required, and compensate the user somehow. After all, Apple encourages such testing. we are working for free when doing it, and many times Apple even sets automatic updates by default in devices.

LikeLiked by 1 person
2

Javier Gallardo on September 30, 2020 at 8:02 am

…at least, I’ve learned something: I’ve unchecked automatic (push) security updates and I have placed “SilentKnight” app in a prominent folder. I want to preserve my system against remote invaders, and Apple has become one of them.
Thanks, Mr. hoakley, for your useful apps.

LikeLiked by 1 person
3

Colstan on September 30, 2020 at 9:11 am

Howard, I appreciate your continued coverage of this topic, thank you for that.

I think the added complexity of the T2 co-processor has often been a hindrance in terms of update stability and recovery. In the past, the firmware wasn’t nearly as complex, and if you had a software-only issue, you could just reinstall to an earlier version. If something funny happens with the T2 firmware, the steps to get your Mac back to a fully functional state are much more involved, and not something a typical Mac user should be expected to remedy.

While Apple Silicon Macs will probably have their own issues to work through, at least there will only be one CPU, rather than an x86 chip + an A10 bolted on. Once the Mac is fully transitioned, perhaps some of the stability issues will resolve themselves. Of course, that is some time from now and there are going to be plenty of Intel T2 Macs to support for “many years”, as Apple likes to vaguely state.

Colstan

LikeLiked by 1 person
- 4
  
  hoakley on September 30, 2020 at 4:46 pm
  
  Thank you.
  I agree that the T2 chip does make some things more complex, and am eagerly looking forward to my next Mac without one. But apart from rare brickings, which seem very infrequent now, I’m not sure that they really make macOS that much more complex. Nor should they ever be an excuse for bad updates.
  Howard.
  
  LikeLike
5

David C. on September 30, 2020 at 9:58 pm

Another data point for the Classic era. System 7.6 (and 7.6.1 that soon followed) was a huge change from 7.5.5. It was the first version that was no longer compatible with computers having only 4MB of RAM – making it incompatible with the Mac Plus and SE.

I would consider that kind of breakage enough to warrant a change to the major version number, but Apple clearly disagreed.

LikeLiked by 1 person
6

Charles on October 2, 2020 at 5:44 am

I can only talk about the OS X era, but I think we miss a truly important and influential fact regarding Apple development cycles:

Until OS X 10.5 Leopard in 2007 (included), all new releases used to be sold at about $130. Therefore, we users/buyers had certain stability “expectations”.

I think the gradual change to first cheap and then free OS X releases was clearly related to an internal transition to a quicker development cycle in order to be aligned to Apple’s ever increasing release of hardware products.

LikeLiked by 1 person
7

Michael Tsai - Blog - Quality Management in Apple’s System Updates Over Time on October 2, 2020 at 7:54 pm

[…] Howard Oakley: […]

LikeLike
8

Bob on October 3, 2020 at 1:04 pm

Perhaps it’s my experience on enterprise-level equipment, but never have I enabled automatic updates on any of my personal platforms; not even my phone. For me it’s an issue of stability, operational continuity, and security. I always like to let updates “bake” for a while. In terms of stability, this article touches on the horrors. In terms of operational continuity, I like to decide when the behaviour of my machine might change, and when it will reboot. (In this way, I can tag a specific Time Machine backup as the checkpoint, and know that I must roll back to there should I notice issues a few days later.) In terms of security, my fear is the compromise of an automated delivery pipeline, turning into the digital equivalent of Lawnmower Man. After a number of days, if the update is not lighting up the internet with horror stories, I’ll apply it. One might argue that this practice lowers my security posture by delaying potentially critical security updates. That would be the case, except for my behaviour as detailed below.

While I use my Mac for many things, the browser isn’t one of them because I consider it to be a major attack vector. Using a browser is the digital equivalent of walking through the city knocking on doors, hoping a monster doesn’t answer. Thus, all of my internet travels occur in a Linux VM. In fact I’m posting this from such a VM. I’ll gladly update the VM platform on short notice because if something goes wrong, I’ll just revert to the snapshot I took before the update. If it gets compromised, it cannot get to the host (Mac) system and I’ll just throw it out and clone another from a baseline; it holds no data. Hasn’t happened yet, but insurance provides security nonetheless. This is how I protect myself from ever-changing software updates, and the vagaries of the internet.

As a result, delaying an update on the host system would only represent a greater security risk under certain specific circumstances so egregious such that malefactor entry can be achieved remotely simply because the machine is turned on. While not impossible, these situations are rare, such as a bug in the TCP/IP stack or VM hypervisor.

LikeLiked by 1 person
- 9
  
  hoakley on October 3, 2020 at 5:31 pm
  
  Thank you. I too disable automatic updates – not least of which is to prevent my Mac trying to install an update at an inconvenient time.
  However, I tend to browse very mundane sites, and am quite content to trust Safari and my own judgement and care. I’ve had a few close calls, but always one that I should have expected, e.g. when trawling Russian sites for images of paintings. I’ve stopped doing that now!
  Howard.
  
  LikeLike
10

Steven Kapplin on October 4, 2020 at 4:14 am

I’ve been part of the AppleSeed program since 10.1 was released. Those who were on the early team were better bug finders than we’ve had since Apple shifted to Public Betas. However, despite the many challenges, such as shifting from a two-year upgrade cycle to a one-year cycle (done at the direction of Steve Jobs,) there has been little change in the general quality of a release, based on the problem reporting that occurred in the old Apple Forums, as compared to the new Apple Support Community.

I don’t think the OS is any buggier relative to the growth in size and complexity of the OS. I’ve used every version of the OS since System 6. They have all had “more” bugs than an African ant mound. I would not be surprised that some of those bugs are still on the list (the less impact on the user, the farther it drops towards the bottom of the list.)

I don’t mean to deprecate the impact defects makes on the user for whatever reason, but every major software producer is faced with the same problem – there is no major software production that has no fatal flaws. And, if there is a fatal flaw, no matter how obscure, then there will be a user that finds it, quite accidentally. As Confucius wisely remarked, “Shit happens,Grasshopper.”

[All opinions expressed above are mine. All errors belong to Grasshopper.]

LikeLiked by 1 person
11

DanC2 on October 5, 2020 at 7:16 pm

All good points here, especially Bob’s Linux-VM. Another method is to use Firefox profiles with extreme protective settings, uBlock Origin and User-Agent Switcher set to some flavor of Windows. This will at least give you a fighting chance if any packages are downloaded. You will need to fiddle a bit to get the correct software downloads in some cases, however. Interestingly, Zoom often seems to use the default browser’s user-agent to determine which installer type to grab even when checking for and running updates within the app.

I think the 10.4 cycle length was certainly due to the PPC – Intel transition, at least in part, which makes sense. Having parallel systems in somewhat lockstep allowed comparison and direct contrast, helping Apple and 3rd party developers see if things were running correctly. It may also have provided a little PR benefit in the “drag race” category as some apps and processes could be shown beating out the PPC.

While I understand the thinking behind allowing more time for certain development phases possibly resulting in testing and QC teams feeling less pressure, you still gain more information and opportunities the longer you remain in the testing phase. If nothing else, it might encourage more people to jump in on the testing.

Regardless, whenever you have a rapid release cycle that is determined more by absolute calendar dates and ecosystem agenda, there is an increased chance of really unfortunate things slipping through to the full release. To some degree this is necessary to prevent endless tinkering, but network security and data loss are not to be taken lightly in this era of intense dependency on cloud computing and digital devices.

When you add secrecy and speak-no-evil to your list of priorities, more really unfortunate things happen.

LikeLiked by 1 person
- 12
  
  hoakley on October 5, 2020 at 9:35 pm
  
  Thank you.
  Howard.
  
  LikeLike