Watch the user forums on MacRumors and elsewhere and you’d never update macOS, or anything else, as there’s always someone who has reported all the horrendous problems that result. So it was that Apple’s first RSR earlier this week has been claimed to cause a legion of errors and faults, among them poor performance of USB 3.x external disks. But how plausible and probable are those problems?

The sealed system

Many of us still think of macOS as if it had changed little since Mojave, when all sorts of errors could and did occur during installation of macOS updates. Prior to Big Sur, that was not only feasible, but undetectable, as neither APFS nor HFS+ use checksums to verify the integrity of file data. A few bits copied incorrectly, sufficient to break important systems, and they have no means of telling what has happened.

With Big Sur, that changed completely. During macOS installation and updating, every file has a cryptographic hash calculated for its contents. Those hashes are hashed again in a tree structure, leading to the seal covering the whole System snapshot contents. A change in only a single bit in one file invalidates that whole branch of hashes, right up to the seal, the system’s signature then fails, and that copy of macOS can’t boot. During the boot process, that signature is compared against that provided by Apple; if the two don’t match then booting from that system stops. In other words, every bootable copy of each release of Big Sur and later is identical, and exactly the same as that supplied by Apple.

Not everything in macOS is contained within the sealed system, of course. Some like Rosetta 2 are installed on demand, and stored on the Data volume. Others like XProtect Remediator are updated outside macOS, and they are also on the Data volume. In Ventura, but not earlier versions of macOS, most of those unsealed components are now provided in Cryptexes.

Cryptexes

The sealed system is extremely robust and secure, but that cuts both ways, as it’s also cumbersome to update. To make a small security patch in one of its components, Apple has to build and test a whole new system, then create an updater, that in turn rebuilds the System volume on the user’s Mac, makes a snapshot, builds its hash tree, and every Mac then has to reboot at the end of that installation process.

The recently introduced Rapid Security Response is based on one of Apple’s oldest technologies, originally dating back to the 1960s, the disk image. When mounted early in the boot process, a suitably designed disk image can be used to extend or patch part of the sealed system. These have to be made secure, to ensure that nothing can alter their contents. The result is the Cryptex, already used to contain Safari, other bundled apps, and other parts of Ventura, and that’s essentially what an RSR installs.

Because it too is a sealed and verified file system, every Cryptex is exactly as Apple intended, and won’t be loaded if it isn’t perfect.

The major snag with RSRs is that their development and release is accelerated, so they undergo more limited testing compared with a regular update. Because that increases the risk of unintended side-effects, every RSR can be readily uninstalled by removing or replacing its Cryptexes.

Did the RSR change SSD performance?

RSRs are quite different from full macOS updates, in containing only the system components that need to be changed. Although Apple hasn’t released full change information on any macOS update for many years, last week’s RSR is likely to make only small and limited changes, most probably to Safari and WebKit, the frameworks and other components that many apps depend on. This makes more general changes, like those in drivers for external storage, unlikely.

To see if I could replicate any effects on the performance of USB 3.x SSDs, I measured read and write performance using Stibium on a test SSD connected to my MacBook Pro M1 Pro 16-inch, before and after installing RSR 13.3.1 (a). This SSD consists of a Samsung 980 Pro NVMe 1 TB SSD in an Orico USB 3.x enclosure, connected by a 0.8 m CalDigit Thunderbolt 4 cable. Recorded speeds are:

• macOS 13.3.1 – read 991 MB/s, write 1030 MB/s
• macOS 13.3.1 (a) – read 992 MB/s, write 1020 MB/s.

There is thus no evidence that RSR (a) has any effect, good or bad, on the performance of that SSD. Although this doesn’t rule out changes in other combinations, it does make them unlikely, or potentially hardware-specific.

Chance and causality

If the system is sealed and perfect, and the only change has come in sealed and verified Cryptexes, what could be the cause of changes observed following an RSR or other update? In many if not most cases, the culprit comes in what isn’t controlled, normally third-party software in /Library and other uncontrolled parts of the boot volume group.

There’s another danger here, in drawing a distinction between chance and causality. I’m afraid there’s a small chance that, in any given day, your Mac might suffer a significant hardware failure in one of the essential components on its logic board. What if that unrelated chance event occurred immediately after you had installed an RSR or macOS update? Do you have sufficient evidence to show that the RSR/update caused the hardware failure?

We all too often attribute causality to what are in fact unconnected events, and in some cases, it even turns out that the problem ’caused’ by an update had arisen before the update was installed. It’s only human to presume causality. Fortunately, because of the design of RSRs, this is more easily addressed than with macOS updates: simply uninstall the potentially troublesome RSR.

Open System Settings > General > About, and look down for the macOS version. At the right of that line is an ⓘ button: click on it to see the dialog above, allowing you to uninstall that RSR.

If uninstalling it doesn’t revert the problem to what it was before installing the RSR, be extremely suspicious of presuming any causal connection. When anyone makes a claim that an RSR has had an adverse effect, if they’re unable to demonstrate its reversal when the RSR is uninstalled, be extremely suspicious of that claim.

Managing risk

The most significant risk with any RSR is relative lack of testing before release. This is countered by its ease of removal, and its relative isolation from the sealed system. Unlike a full macOS update, it makes no changes to the sealed system, and once removed shouldn’t leave any trace.

While macOS ‘minor’ updates, such as 13.2 to 13.3, undergo beta-testing, security updates such as 13.3 to 13.3.1 aren’t made available to developers or the public for testing, and RSRs have more limited internal testing.

If you suspect any macOS update has brought problems to your Mac, first try restarting, and if problems don’t resolve, start the Mac up in Safe mode, leave it for a couple of minutes, and restart it in normal mode. Only then should you consider uninstalling an RSR. Unfortunately, reverting to a previous version of macOS is far more laborious.