Big Sur’s sealed System volume seemed like a good idea. Although the read-only version in Catalina may look impregnable, guaranteeing integrity using a Merkle Tree of hashes, then locking the whole lot in a snapshot, looks even more robust. Like other good engineering ideas, though, it also needs thinking through thoroughly.

Even in a perfect macOS development cycle, there are normally at least five substantial updates. In addition, there are often compelling reasons for urgent patches. The recent sudo bug is a good example in which no one is at fault, although everyone might be to blame for not spotting this in a decade. Even in non-pandemic times, rolling that fix into 11.2 would have been disruptive, hence the need for 11.2.1, which works so much better in the new version numbering.

Then Apple must have received reports of a severe hardware/firmware problem which was actually damaging recent Mac models, and a firmware update for the affected Macs was even more pressing. So came 11.2.2, just over two weeks after 11.2.1, which was a mere eight days after 11.2.

In macOS past, those two patches could have been small, whether installed by the system or using a downloadable Installer package. Several factors now conspire to turn a few kilobytes of changes into several gigabytes of update:

• Firmware updates are only provided as part of a macOS update, and Apple deems it necessary for every macOS update to include a complete set of current firmware for Intel models. This contributes around 600 MB to every update, perhaps more now to cater for T2 and M1 models too.
• The dyld cache, nine files occupying about 4 GB when compressed in /System/Library/dyld, which contains a dynamic linker cache of all the system-provided libraries. These fall within the SSV, and appear to have to be freshly provided in every macOS update.
• Full support for both Intel and ARM-native code, with the exception of Rosetta 2, which only resides on the Data volume of Apple Silicon models and is managed separately.

The Big Sur 11.2.2 update is a good example of what’s almost a null change, yet requires 2.6 GB of installer files to be downloaded for an Intel Mac, and 3.1 GB for an M1 model. For comparison, a minimal update to Catalina required less than 1.2 GB, and for Mojave less than 1 GB, much of which were the seemingly obligatory set of firmware for every supported Mac.

The time required to install these much larger updates has also increased substantially. Before the installation can even start, Big Sur updates now require a minimum of 15 minutes ‘preparation’, just as those for iOS/iPadOS do. The similarities here are made more obvious by a typo in log entries during this ‘preparation’ phase, which refers to the “BRAIN” being used not as macOS but “iOS 11.2.1 20D74 (Customer)”, for instance.

Minimising download time with a local Content Caching Server, second and subsequent updates still require a minimum of around 40-45 minutes, to which M1 models have an additional 1 GB which has to be downloaded from Apple’s servers, and can’t be obtained from the local cache.

As Jeff Johnson has reminded us, Apple still claims that Big Sur has “Faster updates. Once macOS Big Sur is installed, software updates begin in the background and complete faster than before — so it’s easier than ever to keep your Mac up to date and secure.” Anyone who has been keeping Big Sur up to date over this last month knows that’s simply not true, and its reasoning is flawed. Whether updates are downloaded in the background or not, when a null update like 11.2.2 takes more than half an hour to install in addition to its 15 minute ‘preparation’, today’s updates are far more time-consuming than ever before.

What this month has demonstrated, reiterated and rubbed in until the wounds bleed again, is how massive and debilitating updating Big Sur has become. Fixing an issue in the firmware of a few models now requires that everyone running Big Sur downloads 2.6 to 3.1 GB of installer files, then waits as their Mac is unusable during the preparation and installation process of more than forty minutes. For most users with high-bandwidth internet connections, that comes to a total of at least an hour, which is longer than major updates took in Mojave and earlier.

Worse still, if you have the misfortune to be running from an external bootable SSD on your M1 Mac, chances are that you can’t even update macOS, and that can apply to Big Sur running in VMs too.

Had Apple explained these costs and penalties of the SSV at last year’s WWDC, wouldn’t it have been booed from the virtual stage? To make this work for users, rather than its own engineers, Apple needs a radical approach. Instead of every update being based around a universal set of data files, the installer brain needs to work more intelligently. Why does every Mac need a copy of the firmware for every model? How can the burden of dylds be minimised?

If Apple can’t come up with a better solution designed to accommodate the needs of users around the world, many are not going to keep updating, and Big Sur will become the lemon it doesn’t deserve to be.