The few patch updates to macOS Big sur recently have pretty much confirmed that Apple’s promise of faster updates when using macOS Big Sur is not exactly accurate. Apple’s statement was essentially that if you have automatic updates enabled, the process to install the update will be done in the background and you will be prompted to restart once that operation is complete (saving you time). The problem with this is that I don’t have automatic updates enabled as the quality of macOS updates this past year (Catalina) have caused multiple issues and re-releases have been frequent to fix issues caused by the updates. This has continued with Big Sur. So what is different with Big Sur’s update mechanism? Well, 1) There are no longer and Delta or Combo update packages available, 2) the installer must create a new Sealed System Volume (so updates are large and now have a “preparation phase”), and 3) you cannot perform an unattended update on Apple Silicon Macs.
The first issue is more or less an issue if you have to manage multiple machines. In the past, you could download either the Combo or Delta update .pkg from Apple’s support site and then use Apple Remote Desktop to push the update and restart. Now, updates are distributed as .ipsw images so you need to run the softwareupdate command on each machine (or use the System Preferences GUI) to run the update. This process is slightly more efficient if you have a Content Caching server on your subnet, otherwise each machine has to download the update from Apple’s servers. Regardless, the .pkg approach was the most efficient and it is sad to see it go.
The Signed System Volume, however, is the biggest change. Now, every update must be able to create a new SSV, so delta updates are pretty much guaranteed to be multiple gigabytes. For example, macOS 11.2.3 was ~2.4 GB whereas iOS 14.4.1 was ~144 MB for the same security update. The reason for the size difference is that the updates carry firmware for all Mac models and the updated dyld cache (i.e. any framework change requires an entirely new cache). Of course, the apps and frameworks contained in the system are universal (x86_64 + arm64), so they are larger then their counterparts in the previous OS. However, once x86_64 support is dropped, they will go back to roughly their previous sizes. Sizing aside, macOS updates have typically been slower than say Windows updates (except perhaps for Feature Updates) and the new process of creating the SSV, i.e. Preparing, takes 15-20 minutes. Once that is done, the update still needs to install, so that is another 30-45 minutes. So, it looks like this is another case of Security vs. Usability as machines have to download larger updates and take longer to install the updates in order to satisfy a cryptographically secured OS volume. Hopefully the next major macOS release starts to optimize this process so that updates do actually take less time to install (and are hopefully smaller).
The last annoyance is that OS updates now require an administrator to authorize the update via a GUI password entry (on Apple Silicon machines). This means that you can no longer remote into a machine and do the update via CLI, rather, you must be physically at each machine. Not a problem for most users, but for admins, this is a big deal. I don’t understand the reasoning behind this change, but I assume it is related to the fact that macOS is now using the mobile updater from iOS and iOS requires the user to enter the device’s passcode to kick off an update.
macOS 12 definitely needs some adjustments in the update space to return to admins the flexibility to manage their devices efficiently. The question is whether or not Apple thinks that this is a problem worth fixing.