As some of us learned in the last week, it’s easy to uninstall a troublesome Rapid Security Response (RSR). Several naturally asked why that isn’t possible with a macOS update, pointing out that it was available and worryingly popular between High Sierra and Catalina 10.15.2, since when the ability has been lost.

RSRs are designed to be quick and simple to install and uninstall, as they’re rapid patches that don’t undergo much testing, and aren’t released to developers as betas. While Apple doesn’t intend that they cause the problem that arose with Ventura 13.4.1 (a) last Monday, the risk of them doing so is inherently greater.

RSRs are also far simpler than even a very small macOS update, as they don’t change anything in the Signed System Volume (SSV) that your Mac boots from. They’re small well-protected files of a type known as a Cryptex that are loaded separately during the boot process, without any involvement of snapshots or the tree of hashes used to seal the contents of the SSV. Software Update can thus provide a simple option to install a given RSR when it’s available, and to uninstall it by replacing its Cryptexes with those previous to the RSR.

The SSV is far more than the plain snapshots used to make roll back so easy in High Sierra. To create it, it has firmlinks to the Data volume built in, the snapshot is made, then the installer builds a tree of cryptographic hashes to include its entire contents, culminating in the seal. That’s a hash of the hashes in the next level down, and so on until you reach individual files in that snapshot. These enable the entire contents of the SSV to be verified down to the last bit. A hash is made of that seal, to act as the signature of the SSV, and compared with the value set by Apple for that version of macOS.

In the days of High Sierra, through to Catalina, macOS updates were essentially large and complicated Installer packages. The actions required to create the SSV require far more than the Installer app could ever achieve, so each macOS installer and updater comes with its own ‘update brain’ to handle these tasks. While in theory an update could leave the old SSV alongside the new, being able to roll back to the old would present major difficulties, including:

• The old SSV would occupy up to 9 GB of disk space until it’s deleted. While some users might be happy to lose that, the great majority wouldn’t. Some mechanism would also be required to delete the old SSV and commit fully to the update when the user is happy to do that.
• To be able to roll back to the previous SSV, all the firmlinks between the updated SSV and the Data volume would have to be broken, and remade between the old SSV and the same Data volume. All the evidence is that wouldn’t be easy, could be unreliable, and may not even be feasible. Without that, roll back couldn’t work.
• As some of macOS is still installed on the Data volume, reverting that would need to be addressed separately.
• None of this would address the problem of rolling back firmware updates, although those are often the primary reason for wanting to return to the previous version of macOS.
• Roll back would require its own software tools, perhaps in a separate updater-like download.
• There’s a risk that a roll back would result in the SSV’s hash tree and signature being broken. Provision would therefore be required to reinstall that older version of macOS.

For those who decide that they want to roll back a macOS update on an Apple silicon Mac, by far the simplest procedure is to back the Mac up fully, put it into DFU mode, use Configurator 2 to restore the IPSW image for the previous version of macOS including its firmware, then to migrate the backup to that fresh boot disk. That also caters for all problems that may have arisen with the update.