Updating macOS is widely held responsible for all manner of problems. If you’re unlucky and a firmware update turns sour, or your Mac’s internal storage gets scrambled completely, then that’s fair cause. But since Big Sur, with the introduction of the SSV (signed and sealed System Volume), updates should have become extremely reliable. Yet users still report problems.

While traditional macOS updates were fairly simple to understand, these modern updates are more complex. But however they achieve it, at the end the snapshot your system runs from has to be bit-perfect. At least on T2 and Apple silicon Macs, every byte in that snapshot is checked against a tree of cryptographic hashes, and only if the Seal at the top matches that prescribed by Apple will that system be bootable.

Most of the problems experience by users, though, are more likely to be attributable to changes or errors in the Data volume, which isn’t sealed. What’s confusing here is that Apple’s official word is that a modern update doesn’t alter the file system or data on the Data volume. In its Platform Security Guide, Apple states: “Finally, the user’s data volume is never mounted during a software update, to help prevent anything being read from or written to that volume during updates.”

With a verifiably perfect System volume and firmware, if the Data volume has remained unmounted during the update, what could possibly have changed? The answer lies in what really does happen during a macOS update.

Big Sur and Monterey run almost all their system software from the mounted snapshot of the System volume, but not everything can be installed there. Among the most notable exceptions are Safari and various CoreServices.

In the Finder, select one of the apps bundled with macOS, such as Reminders, and open a Get Info dialog on it. Its path is shown as being in
Macintosh HD/System/Applications, which locates it within the System volume, and the SSV. Repeat that with one of your own apps, and the path given is different, such as Macintosh HD/Applications, which is located on the Data volume. Now inspect Safari, and you’ll find it on the Data volume as well.

If the Data volume were literally never mounted during the whole of a macOS update, then the only components in Safari that could be updated are those on the System volume, particularly WebKit and its supporting frameworks, and the app itself couldn’t be changed or replaced. Another common observation during Big Sur and some Monterey updates is that some install an older version of security data files, which are found in the path Macintosh HD/Library/Apple/System/Library/CoreServices, firmly on the Data volume. This similarly applies to Rosetta 2.

What I think Apple means by that sentence is that the Data volume is unmounted during installation of files on the System volume, and generation of the SSV. But once that phase of update installation has completed, and the update process comes to install system components on the Data volume, that volume has to be mounted. Maybe it’s at that point that troubles begin for some Macs.

This could also explain why installing or re-installing macOS can still fix problems, even though the SSV generated is absolutely identical. As its cryptographic hash tree doesn’t extend across firmlinks to the Data volume, there’s no guarantee that’s perfect in the folders that contain parts of the system.

Ventura is set to change this again, with its support for what Apple calls Rapid Security Response, in which patch updates can be saved to protected storage on the Preboot volume. These are cryptex disk images, cryptographically sealed extensions, where Safari will be stored in the future. It may then be possible for the whole of a macOS update to complete before the Data volume is mounted. Then we’ll have to devise another universal panacea for all those problems which can occur after a macOS update.