Following a general outline of what happens during a macOS 26 update, and a more detailed account of how it uses finite state machines and sends progress reports to Apple, this article describes what happens before Software Update downloads the main update. This was started by opening Software Update in System Settings of macOS 26.2 when the update to 26.3 was available, on a Mac mini M4 Pro. The Appendix at the end explains several in-house jargon terms used widely through these log entries.

Check for an update

In this case, checking for an update was instigated by opening Software Update in System Settings. That initiated a series of preliminary checks to:

• determine whether that Mac and user are enrolled in a beta-test programme;
• obtain the Pallas audience, in this case macOS Customer;
• determine the time interval since the last scan for updates, and its result. As that was 632.8 seconds ago and there were no updates reported as being available then, a further scan is deemed acceptable;
• set the base URL for Pallas of mesu.apple.com/assets/macos/.

A new scan for updates is started, with a UUID chosen to identify it. The UUID used is version 5, so is expected to be based on a hash of other identifiers, and is unique to this software update. The catalogue is downloaded from Pallas, and analysed for new versions being offered for download.

In this case there are two available:

• macOS263Short comes with just an arm64e system cryptex at 6,458 MB, and a download size of 3.68 GB which unarchives to 4.36 GB;
• macOS263Long comes with both arm64e and x86_64 system cryptexes at 6,458 + 2,312 MB, and a download size of 17.48 GB which unarchives to 18.14 GB.

Both of those use the Zip compression algorithm, and are designated as being ZipStreamable. macOS263Short is clearly the Delta update from 26.2, whose download size was then displayed in the Software Update panel. macOS263Long appears to be a full upgrade, equivalent to the macOS Installer app in terms of its contents.

A similar sequence of events occurs when you request a list of available macOS installers using the command
softwareupdate --list-full-installers

Routine checks

The following checks are repeated at frequent intervals throughout scanning and preparation:

• the presence of rollback objects, a rollback copy of cryptex1 in the Preboot volume;
• whether semi-splat is active, by comparing the Splat RestoreVersion with the Cryptex1 RestoreVersion;
• whether the root volume is sealed;
• whether this is an emergency update;
• battery level, even in Macs without a battery.

Sizing

Early estimates are made of the size required to prepare and apply the update. Prepare size consists of:

• a cryptex size requirement, consisting of the sum of the sizes of the app and system cryptexes, multiplied by 1.2, in this case a total of 7,809 MB;
• a snapshot prepare size, consisting of the snapshot installation size of 3,785 MB plus the cryptex size, for a total of 11,595 MB.

These total 11,595 MB when first calculated, but a little later the snapshot installation size was increased to 5,154, for a total of 12,963 MB.

The apply and reserve size consists of twice the update partition size plus the update APFS reserve of 700 MB, plus 231 MiB for volume sealing overhead, giving a total of 931 MB. Presumably any shortfall in free space available would be notified to the user at this stage, and the update cancelled.

The policy for updates is determined in detail, before Pallas is asked for a catalogue of MacSplatSoftwareUpdate, updates using cryptexes, probably including both older RSRs and their successor BSIs. In this case, that catalogue is empty.

Mobile asset catalogues

softwareupdated then takes a back seat for much of the following 15 seconds or so, as mobileassetd determines which mobile assets need to be updated. These are the multitude of components to support Siri, AI and other features. This too is run by a finite state machine, AutoControlManager, which downloads catalogues of these components to assemble its auto-stager. One catalogue alone lists 91 available for update, but thankfully many of those don’t need to be updated.

Once that’s complete, the progress bar is displayed and updated by softwareupdated.

Progress bar

This is divided into zones used for different stages of progress by softwareupdated. These can be summarised as:

• 0.0-0.9 prepare
• 1.0-7.0 reloading and downloading Update Brain
• 7.0-15.0 preflight
• 15.0-55.0 downloading
• 55.0-60.0 preflight FDR Recovery
• 60.0-100.0 preparing update

During the downloading and preparing stages, progress updates are made according to the amount of the stage that has been completed. Otherwise they are made when each stage has been achieved.

In practice, progress is most meaningful during the downloading and preparing stages, between percentages of 15-55 and 60-100. Time estimates are displayed for both of those separately, with download time remaining based on size transferred. Once downloading is complete, the final 40% of the bar is given a fixed period of 30 minutes to complete, although that’s never required now.

Initial preparation

softwareupdated determines and downloads the cryptex updates, any SFR software update, any Rosetta update, any RecoveryOS update and the RecoveryOS update ‘brain’ for that. These are set up with their own finite state machine that downloads the catalogue, determines what should be downloaded, and downloads it. The final phase handles the documentation for the update, in this case consisting of

• release notes summary, 1,268 B
• release notes, 1,243 B
• licence agreement, 97,187 B.

There’s an irony here that the first two are so tiny by comparison with the last.

In this case, downloading the update was completed within 10 minutes of obtaining the first update catalogue from Pallas.

Summary

• After preliminary checks on beta enrolment and the period since last check, a catalogue of available updates is obtained from the software update server.
• That catalogue offers a short Delta update, and a long full update.
• Downloaded updates are compressed using Zip, and decompressed as they are streamed in the download.
• Sizes required for preparation and applying the update are checked and adjusted.
• mobileassetd determines a potentially long list of mobile assets to be updated.
• Progress is displayed according to a combination of downloading between 15-55%, and preparation between 60-100%. Other stages are defined by progress through required steps rather than time.

Appendix: Terms used

• Pallas is the internal name for Apple’s software update server. This appears throughout log entries, where for example Pallas audience is jargon for the type of user, normally macOS Customer.
• RecoveryOS appears to refer to the version of Recovery in the hidden container of the internal SSD, more widely known as Fallback Recovery.
• SFR appears to refer to the version of Recovery in the Recovery volume of the active boot volume group, also known as Paired Recovery.
• Splat, semi-splat and rollback objects all refer to cryptexes. Splat is the general term, while semi-splat refers to a cryptex-based update that might include rapid security responses (RSR) and background security improvements (BSI) implemented by replacing one or both cryptexes. Rollback objects are older versions of a cryptex that have been saved to allow a newer cryptex to be reverted to that older one, in the event that the newer cryptex causes problems.