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

The general rule with security certificates is that they’re only valid until their expiry date. When the certificate for a website expires, your browser should warn you if you try to connect to that site, and it will normally refuse to make the connection as a result. Thankfully, Apple’s signing certificates generally work differently.

When Apple adopted code signing using certificates that it issues, it recognised that applying that policy would result in apps having expiry dates enforced by their certificates, so applies a different rule. When a developer signs an app using their Developer ID Application certificate, a trusted timestamp is included to verify when that signing took place. Provided the certificate was valid at that time, and hasn’t been revoked since, the certificate is deemed valid by macOS.

The same principle applies to Developer ID Installer certificates used to sign install packages, only for several years they weren’t given trusted timestamps. As a result of that, those old installer certificates were only valid as long as the certificate.

Apple changed that several years ago, since when installer packages have normally been given trusted timestamps, so they now work the same as Developer ID Application certificates, and can still be run successfully after their certificate has expired, provided that it was valid at the time in their trusted timestamp, and hasn’t been revoked since. However, this has only recently been reflected in Apple’s guidance to developers, and is different from the account I gave here last week.

Check validity

Trying to open the app or installer package usually isn’t the best way to check whether its certificates are valid. Although you may sometimes be given an informative explanation, in most cases macOS will simply report the item is damaged and needs to be removed, leaving you in the dark as to what the problem might be.

The best way to check the validity of Apple’s certificates is using Apparency for apps, and Suspicious Package for installer packages. They will provide a detailed explanation of why the signature is valid or not.

Apps

Apps supplied from the App Store are signed not by the developer, but by Apple. According to Apple’s current account, their signatures will remain valid as long as the developer remains a member of its Developer Program.

Apps supplied independently are signed by their developer using their Developer ID certificate issued by Apple. Provided that the app’s certificate was valid at the time it was signed, and that certificate hasn’t been revoked by Apple, that will remain valid indefinitely. The same appears to apply to notarisation, which should remain valid unless Apple revokes it.

Although there’s nothing to stop developers using certificates from third party authorities, macOS doesn’t recognise those and will normally block the app from being run. If you ever come across one, contact its developer and tell them the certificate they’re using is wrong.

Installers

Older installers are likely to have been signed without a trusted timestamp. If that’s the case, they will cease being valid when their certificate expires.

More recent installers should have a trusted timestamp, in which case their signature will remain valid unless Apple revokes their certificate.

Complications

Some certificates, most notably those used by macOS installers and updaters, also rely on the intermediate Apple Worldwide Developer Relations certificate, which underwent a hiatus on 24 October 2019 when an old certificate expired and was replaced by a new one, which expires on 20 February 2030. That expiry will still limit the validity of some old signatures.

Some apps require restricted entitlements, issued by Apple to allow them to access features that are normally not allowed, such as making snapshots and bridge networking in macOS VMs. Although those should expire well into the future, they can rarely have their own expiry problems that could prevent an app from running.

Examples

This old Catalina installer app was signed without a trusted timestamp. Now that its certificate has expired, it’s likely to be unusable.

This macOS update installer package was also signed without a trusted timestamp, its certificate expired in the 2019 hiatus, and it’s now unusable.

This third-party installer package was signed in 2017, but has a trusted timestamp. Even though its certificate expired in May 2017, because it was still valid at the time of the trusted timestamp it should still be deemed valid.

This third-party installer package was only signed last July, but its Developer ID Installer certificate expired the following month. Because its certificate was valid at the time of the trusted timestamp it’s still deemed valid.

Further reading

Signing certificates (Apple)
Developer ID and provisioning profiles (Apple)
Apple Intermediate Certificate Expiration (Apple)

I’m very grateful to Quinn for drawing my attention to this.