If you’ve already updated to Ventura 13.0.1, you might have noticed that the whole process seemed to run more quickly than similar updates in Monterey, and far quicker than those in Big Sur. Not all Macs are equal, though, with Apple silicon models coming out best, many of which completed that minor update in less than ten minutes. This article takes a look at what happened during that update, and shines a little light on macOS’s new Cryptex system files.

To look at this in detail, I updated Ventura 13.0 in a virtual machine (VM) running in my virtualiser Viable on a Mac Studio M1 Max. This is a good platform for studying macOS updaters, as it’s easily repeatable as many times as you like, by creating multiple VMs.

As observed, macOS updates consist of three phases:

1. Download, from the start of the update to the start of preparation, here a period of 3:43 (minutes:seconds).
2. Preparation, nominally given as 30 minutes, but in fact only taking 4:33 in a 4-core VM.
3. Installation, from clicking on Restart until the updated system restarts, here 1:45. Some time after that, the user will either be automatically logged in or presented with the login window.

The reality is different. Watch Activity Monitor during those phases, and you’ll see that the download phase has significant CPU use by com.apple.StreamingUnzipService, which as the subsystem name suggests is decompressing the download as it arrives on your Mac. Understanding what’s going on during preparation requires browsing the log, where there’s evidence of further small downloads, some decompression and preparation of updates, and installation.

Although the progress indicators and times shown during updates in Big Sur and Monterey seem to have been broadly accurate, for Ventura they’re wild overestimates. That’s because the total time expected remains 30 minutes, and progress isn’t measured in terms of real time, but using staging points in the process. Hopefully as this matures in Ventura, the progress bar will be linked back to real time.

Download phase

In this case, the main payload to be downloaded for the 13.0.1 update is a Zip archive located at https://updates.cdn-apple.com/2022FallFCS/patches/%5B…%5D/com_apple_MobileAsset_MobileSoftwareUpdate_MacUpdateBrain/%5B…%5D.zip. Its size is given as 0.85 GB, which expands to 1.0 GB, out of a total indicated download size of 1.46 GB. Thus around 0.6 GB of the 13.0.1 update is composed of downloads additional to that main payload.

Activity during this phase is initially dominated by two subsystems in addition to the downloading process: com.apple.SoftwareUpdateMacController and com.apple.mobileassetd. During download, streaming decompression is performed by com.apple.StreamingUnzipService, which fills the log for much of this phase.

Preparation and Installation phases

In Activity Monitor, this is dominated by the ‘Update Brain’ service, which is central to preparation and installation. In the log, this appears as the subsystem com.apple.MobileSoftwareUpdate.UpdateBrainService, which typically takes around 100% CPU with its 6 threads, although it can rise to as much at 300% at times.

Preparation is exceedingly complex. It contains preflight, additional downloads apparently including the Recovery update, and many components unfamiliar to users, such as com.apple.MobileAsset.Trial.Siri.SiriFindMyConfigurationFiles.

Late in the preparation phase, Cryptexes are installed as ramrod splat installs. Splat refers to the Cryptex system to be used in future by Rapid Security Response updates, and already used to extend the System on the Data volume, for Safari and dyld caches. The Cryptexes and supporting files installed by the 13.0.1 update include:
os.clone.dmg (Cryptex) and its root_hash and trustcache
app.dmg (Cryptex) and its root_hash and trustcache
RestoreVersion.plist
SystemVersion.plist
BuildManifest.plist
apticket.vma2macosap.im4m
These are found on the Preboot volume, in the path /[UUID]/cryptex1/current/

A little later, the kernel mounts the System volume ready for updating, the first in a series of volume manipulations. Periodically installation is interrupted by prolonged clearing of caches. com.apple.MobileSoftwareUpdate then applies the patches in the update. Once all updating has been completed and the system is ready for restarting, everything is shut down, then the reboot is performed, and kernel launch is marked by the usual announcement of
=== system boot: A6F75ACD-2729-4AF5-A238-C60F352B7E07

What has changed since Big Sur?

In the two years since the first update to Big Sur using this new system, a great deal has changed. My original exploration of updating then bears little resemblance to what Ventura does. Apple’s engineers have reduced the size of a minimal update to less than half that seen in Big Sur, and the great majority can now be delivered from a Content Caching server.

Streaming decompression and integration of operations have also greatly improved the efficiency of macOS updates. Moving bulky components such as dyld caches into Cryptexes has significantly reduced the size of and time taken by updates. However, it now appears unlikely that update sizes or install times are to fall much further than those in Ventura.