If you keep your Mac up to date with the current version of macOS, at least half a dozen times a year you’ll install an update to bring it to the latest version. This article explains how those updates have worked in recent years.

Before Big Sur

Before we upgraded to Big Sur, macOS updates were relatively simple and based on Installer packages, structured collections of files that are copied to the boot volume in accordance with scripts, run by the Installer app. Once that copying is complete and the boot volume contains the files forming the new version of macOS, the Mac can be rebooted from those.

This system update in Mac OS X 10.1.3 in March 2002 was installed by the Installer app following authentication.

This became more complex with macOS 10.15 Catalina, as that was the first to divide what had previously been a single boot volume into two, System and Data. The diagram below shows in miniature what happened during the course of Catalina’s first two minor updates, as an example.

Upgrading from Mojave to Catalina 10.15.0 was performed using Installer packages that completely replaced everything in its system, created in a new System volume, as shown at the top. This was referred to as an upgrade, as the whole system was installed afresh.

Then (skipping a Supplemental Update) came the first minor update to 10.15.1 on 29 October 2019. For the sake of this example, consider that includes a new version of the cat command tool. Rather than that update containing the whole system all over again, it only contains and installs what has changed, including that new cat binary.

Then on 10 December 2019 Apple released the update to 10.15.2, containing another set of changed files, this time perhaps replacing the cp command tool. There are two ways to install that update, either as a delta update or a Combo. The delta update contains the changes from 10.15.1, here cp; the Combo update contains everything that has changed since 10.15.0, both that in 10.15.1, here cat, and in 10.15.2 with cp.

Combo updates tackled what was then a not uncommon problem, when a previous update hadn’t been installed correctly. If the update to 10.15.1 didn’t actually install the new cat and we then installed the delta update for 10.15.2, the latter may not have worked properly. As there was limited error checking in those old updaters, we would then be using a flawed installation of macOS. By installing the 10.15.2 Combo updater instead of the delta, the chance of errors like that were significantly reduced.

Because updates, whether delta or Combo, were Installer packages, Apple not only supplied and installed them using Software Update and its command tool equivalent softwareupdate, but they were also provided for download from webpages in Apple’s Support site. If you had more than one Mac to update, it made sense to download and use the update package.

Big Sur and the SSV

Catalina’s novel boot volume group, with its separate System and Data volumes, was only an intermediate step to Big Sur, which brought the greatest structural change in Mac operating systems since the introduction of Mac OS X twenty years earlier. The great majority of macOS now runs from a mounted snapshot with a read-only file system separate from that of user files on the paired Data volume, and requires a fundamentally different method of installation and updating.

In addition to updating the contents of the system, from Big Sur onwards installers and updaters have considerably more to do. Those tasks include creating the new snapshot to contain the bootable copy of the system, firmlinking that System snapshot with its paired Data volume, building a tree of cryptographic hashes so that the snapshot can be sealed, and verifying the signature of its seal against Apple’s requirement.

These changes can be seen by following Big Sur’s first couple of updates. On 14 December 2020, the update to 11.1.0 might have gone through similar changes to Catalina, with the replacement of its cat command tool. Once that had been installed on the System volume, a snapshot was made of that System volume, hashes were computed for all its contents, and assembled into a tree. At the top of the tree, a hash of all the hashes in the next layer down forms its seal, which is then hashed again to form the signature of the Signed System Volume (SSV). This signature is compared against that set by Apple for the whole volume, and only if they’re identical is the System snapshot accepted for use. There’s no room here for the slightest error if the signature on the SSV is going to match its requirement.

When that was updated again to 11.2.0 on 1 February 2021, perhaps with a new version of the cp tool, the new installer repeats this process of creating a new snapshot, building its tree of hashes, sealing them, creating the signature, and comparing that with Apple’s signature. This means that each and every update is verified to be perfect, and no errors are tolerated.

Safari and dyld caches

Not all the system is installed in the SSV. Apart from some separately updatable components such as XProtect, Apple decided to make Safari and its supporting WebKit components capable of being updated without going through the process of building a new SSV, so in Big Sur and Monterey they were installed on the Data volume. Accompanying those were large dyld caches containing frameworks and more. That changed in macOS Ventura, since when they have been delivered as cryptexes, sealed disk images that APFS can graft into the file system. Apple also used the same mechanism to deliver a few Rapid Security Responses (RSR), before discontinuing them.

dyld caches are one of the few parts of macOS that is single-platform. While Intel Macs are only provided with an Intel version, those on Apple silicon Macs include both architectures, to support Intel-only apps running in translation by Rosetta 2. The second set is largely responsible for the fact that Apple silicon Mac updates are invariably larger than those for Intel Macs.

Apple has since redeveloped its RSR mechanism, and has introduced them as Background Security Improvements (BSI) in Tahoe, although none has yet been released to the public.

Upgrades and updates

Installing a new major version of macOS to go from 10.13 to 10.14, for example, had been accomplished by Software Update downloading a full Installer app, which then replaced the whole of the old system with the new one. From macOS 12.3 that changed, and whenever possible macOS now effectively performs an update by replacing only changed files before it builds the new SSV. This has reduced both the download time required and that needed to decompress and prepare the update.

This has had the side-effect that ordinary non-admin users can now upgrade macOS from one major version to a later one, an action that previously required admin privileges.

Combo updates

In the new system from Big Sur onwards, Apple only provides Combo updates for those updating from versions of macOS older than the previous version, and only when required. If you were to update straight from 15.0 to 15.2, then your Mac downloads all that it requires for that update. If your Mac is already running 15.1, there’s no option to install the changes in 15.1 again, nor should you need to, as its installation in 15.1 has already been verified as being identical to Apple’s reference.

If you felt that wasn’t adequate, then the only option is to install the whole of 15.2 from scratch by running the Sequoia 15.2 Installer app. More recent installers are more likely to complete this without disturbing the Data volume, and requiring its migration from a backup.

Although these complexities may seem bewildering, macOS updates conceal all of this from the user and most commonly work transparently. However, it can explain why some updates can turn out to be significantly larger than expected.

Further reading

A brief history of installing Mac OS: Mac OS 9.1
A brief history of installing Mac OS: Mac OS X and beyond