Updates to Big Sur have been mixed blessings. On the one hand, we’re all delighted that Apple is fixing bugs and, most important of all, closing security vulnerabilities as soon as it becomes aware of them. On the other hand, you can almost hear the moans about several gigabytes download and yet another hour or more of installation.

What’s most striking isn’t their frequency – 11.5.1 is only the tenth update to Big Sur, the same as in Mojave and less than Catalina’s dozen – but their size. The smallest updates to Mojave and Catalina came in at 1 GB, while 11.5.1 was Big Sur’s smallest yet at more than double that size for an Intel Mac, and triple for an M1 model. As of 11.5.1, M1 Macs have now had over 43 GB of macOS updates, and Monterey must still be at least six weeks away.

Big Sur 11.5.1, like 11.2.2 before it, is as minimal as updates get, containing a useful payload of no more than a few megabytes at most. So how come it’s necessary to download 2.2-3.1 GB and wait 15 minutes for ‘preparing’ of the update?

One policy which has led to the inexorable growth in the size of macOS updates is that each is universal: Apple only releases one update, which has to install and update all Macs supported by that version of macOS. Coupled with its policy that only macOS updates can contain firmware updaters, it means that each has to contain a complete set of firmware updates for all supported models. Those for Intel Macs amount to more than 600 MB, and that for M1 models must also be substantial, and regardless of which model you’re going to update, the download contains a complete set.

It also means that each update is a Universal binary, containing a complete set of executable code to run native on both Intel and Apple Silicon Macs. Executable code doesn’t make up the majority of the system or its updates, but is a substantial proportion. There’s another quirk too: although the main body of each update, at least 2 GB, is common to both Intel and Apple Silicon architectures, and can be delivered from a Content Caching Server, just over 900 MB has to be downloaded individually to each Apple Silicon Mac at the start of every update, and can’t be cached locally. It’s this that appears to account for the difference in size between Intel and M1 Mac updates.

Big Sur’s Signed System Volume also plays a part. Rather than have two or more different variants of each release of macOS, Apple’s policy is for there to be just one, with a single Seal for all installations of 11.5.1, for instance. Architecture-specific features such as Rosetta 2 are therefore stored on the Data volume, and the System volume contains system files which are common to any and all Macs which can run that version of macOS.

Big Sur has also brought internal changes which are widely believed to be important in adding to the size of updates. One is the use of cache files for the active contents of Frameworks and Private Frameworks code. These are assembled in /System/Library/dyld, and behave very oddly. The first thing that strikes you is that every Mac, regardless of its processor, contains three copies of the dyld shared cache for separate processor architectures, x86_64, x86_64h and arm64e. Each of those is given as being around 2.4 GB in size, meaning that there would appear to be nearly 5 GB of totally redundant dyld shared cache on every Mac running Big Sur.

Look at those files, though, and they don’t appear to be that big, each occupying around 1 GB on disk despite a file size of more than double that. In case you’re thinking that they must be APFS sparse files, the file system doesn’t report them as being regular sparse files, neither are they bundles. It’s not impossible that some of their content is ‘cloned’ with one another, but that’s not confirmed by their APFS flags.

Whatever the causes of these very large updates, and however much you try to reduce their impact by using the Content Caching Server, they’re more than mere inconvenience to the user. Unless Apple improves its design of macOS updates, they will continue to plague those who have upgraded to Big Sur, regardless of whether they upgrade again to Monterey. Imagine every single Security Update to Big Sur having a minimum size of 3.1 GB on Apple Silicon Macs. How many users will simply not update, which surely defeats their whole purpose?

Postscript

Thanks to Jeff Johnson @lapcatsoftware for pointing out what should have been obvious about the dyld files: they’re compressed (a longstanding feature of Mac file systems which has never been made available to third parties). However, that raises another problem with the theory that Big Sur updates are made so large by containing a set of dyld files. As they’re already compressed on disk, they’re unlikely to compress much further in an updater. I’ve just tried to compress them using AppleArchive (which was introduced in Big Sur), for example, and they still come to a total of 3.46 GB. It’s a mystery then how a Big Sur updater can contain firmware updates, plus at least 3 GB of compressed dyld files, in as little as 2.2 GB for an Intel Mac. It’s also unclear why updaters should have to include a complete set of dyld files even when, as in 11.5.1, no changes appear to have been made to any frameworks at all. More investigations are needed.