You may have heard my deep sigh of disappointment last week when I looked through macOS Tahoe 26.1. Despite its bumper crop of 90 fixes for security vulnerabilities, as a scheduled update it has two major flaws. It is at once an opportunity ignored, and a failure to learn from history.

Liquid Glass

Ever since the first beta-release of Tahoe reached developers in June, its human interface has been lambasted like no other. Apple has had a torrent of objections to several of its new features, including the gross rounding of corners of windows and controls, its bland and indistinguishable icons, interference between overlaid content, and its uniform bleached-out tone. In those five months, there has been no shortage of suggestions as to what needs to be improved.

Apple’s response is a Liquid Glass control in Appearance settings that purports to provide a “tinted” variant that “increases opacity and adds more contrast”. As I demonstrated early last week, it does neither, and in Light mode in the great majority of Apple’s own apps, this “tinted” variant doesn’t make a blind difference.

Above is Light mode, Liquid Glass set Clear, without Accessibility. Below is the same, but with Liquid Glass set to Tinted.

After many attempts to find some difference between Clear and Tinted in the bundled apps I use most often, I’ve decided that they are visually identical. And where the Liquid Glass effect results in optical interference between layers, Tinted doesn’t alter opacity to eliminate that interference.

This is illustrated in the defaced search box at the top left of System Settings, where the blurred contents of the navigation sidebar at the left remain visible underneath the window’s search box. I can’t understand how any designer could see that released to the public, and providing the new Liquid Glass setting is farting into a hurricane.

Background Security Improvements

Although Apple went out of its way not to let us know, I’m actually glad to see the return of Rapid Security Responses (RSR), even if they’ve been given this sanitised name. What disappoints me deeply is that the BSI shows no sign that Apple has learned from its past mistakes with RSRs just over two years ago.

RSRs, which have never been officially declared dead, were downloaded through Software Update, and gave the user the choice of installing them automatically, downloading and installing them when they chose to, or ignoring them and waiting for the next macOS update. Not only that, but once installed, they could be removed and macOS reverted to its previous state.

What Apple never did get right is how to number the macOS version once an RSR had been installed. Rather than extend version numbers consistently with a fourth digit, Apple decided to append a letter in parentheses, making 13.4.1 become 13.4.1 (a) when its first RSR had been installed. When the first RSR was released on 1 May 2023, Safari’s build number was changed, but not its version number. But with the second RSR on 10 July, someone mistakenly changed Safari’s version number from 16.5.1 to 16.5.2 (a), and that was therefore given as its User Agent, and promptly broke many major websites including Facebook.

Because that RSR could be removed by the user, there was an immediate solution, and Apple delivered a revised RSR a couple of days later.

From this, we learned that:

• RSRs undergo very little testing before release, as they’re supposed to be issued quickly.
• Because they undergo such little testing, their chances of significant incompatibilities are greater.
• Giving the user the option to delay installing an RSR saves many from being caught out by flawed RSRs.
• Giving the user the option to uninstall an RSR is essential in the event that one proves to be flawed.
• Knowing when an RSR is being installed is essential if users are going to be able to identify the cause of problems arising from them.
• Numbering of macOS versions needs to be restructured to accommodate RSRs.

Now, over two years later, it seems Apple has forgotten those lessons. It won’t even describe these as security updates, but “improvements”, won’t include them in the release notes for 26.1, hides their single control at the very bottom of a long list in Privacy & Security settings, rather than in Software Update, provides no manual option, and no means to uninstall them.

I wonder how long it will be before we all regret those decisions, and have to repeat past mistakes before we can learn from them.

If you have updated your Mac to Tahoe 26.1, you may be blissfully unaware that it will now automatically download and install some security updates, regardless of its Software Update settings. Open Privacy & Security settings, scroll down to the end and you’ll see a new item, Background Security Improvements, that Apple has kindly turned on for you. There are matching new settings in iOS and iPadOS 26.1 that are also enabled by default.

Apple seemingly forgot to mention these when listing the changes in 26.1, and its documentation of these Background Security Improvements (BSI) is sketchy to say the least. However, the description there as “lightweight security releases for components such as the Safari browser, WebKit framework stack and other system libraries” is so similar to that for RSRs as “improvements to the Safari web browser, the WebKit framework stack, and other critical system libraries” that we can only conclude the BSI is a rebranded RSR.

What is an RSR/BSI?

Although almost all of macOS is contained in the System volume, turned into a snapshot that’s protected by a tree of hashes with a signature, then mounted as the Signed System Volume, there are additional components that are delivered in separate cryptex files. These are also heavily protected with signatures to verify their contents, and are mounted well after the kernel has booted. APFS then grafts them into the root file system so their contents appear in the correct places. There are currently two main cryptexes common to all Macs, one containing Safari and its WebKit components, the other with dyld caches supporting frameworks. Apple silicon Macs additionally have many smaller cryptexes to support AI and related features.

Because those cryptexes are separate from the SSV, they can be unloaded, replaced with updated versions, and reloaded without necessarily having to reboot the kernel, or go through any of the complex procedures to update macOS itself. Apple first tested this new type of update, a Rapid Security Response (RSR), in beta-releases of macOS 13 Ventura, and the first was publicly released for Ventura 13.3.1 on 1 May 2023.

How do RSRs work?

RSRs have been released using the regular Software Update mechanism, controlled in its settings, and can be uninstalled manually even if you have opted for them to be installed automatically.

To remove an RSR, you 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 it.

Why don’t we get RSRs now?

Apple proudly announced RSRs at WWDC in June 2022, and they were listed among the new features in Ventura: “Get important security improvements to your devices even faster. This isn’t a standard software update. These improvements can be applied automatically between normal updates — without a restart.”

Although the first in May 2023 seemed to go well, the next on 10 July was an embarrassing disaster. RSR 13.4.1 (a) fixed one WebKit vulnerability, but unfortunately it also changed the version number of Safari to 16.5.2 (a), which was reflected in its User Agent, so broke access to many popular websites including Facebook. That had to be rectified in RSR 13.4.1 (c) released three days later. And all three of these RSRs required the kernel to be rebooted after their installation.

Since then, as far as I’m aware, Apple hasn’t released any further RSRs, although they’ve still been referred to throughout its documentation.

Their greatest limitation is that they can only fix vulnerabilities that are confined to Safari, WebKit and other components that are delivered in cryptexes. More commonly, urgent security patches also require changes to software in the SSV, for which the only solution is a full update. For example, during the year that macOS Sequoia was current, it received six patch updates in between those scheduled. Of those, only two might have been suitable as RSR/BSI updates, as all the others required changes to the SSV.

How do BSIs work?

If Apple’s current account of BSIs is complete, the only control we have over them is whether they’re downloaded and installed automatically. If you opt for that, as Apple has set as the default, then you won’t be given any warning, or even informed when the BSI has been installed on your Mac. The only way you’ll be able to learn that is by trawling through the list of software installations in System Information, although Apple will post information about the BSI in its security release notes, following its release.

If there’s a problem with a BSI, such as that in the second RSR in July 2023, then there’s no option to uninstall the BSI and revert to a previous version of that cryptex, as there was with RSRs. However, Apple might decide to remove the BSI from your Mac.

Given the short and unfortunate history of RSRs, that might appear surprising.