Last week, after months of waiting and a few beta tests, Apple released its first RSR, Rapid Security Response. As far as we can tell, it seems to have been a success, with all Macs running Ventura 13.3.1 offered the update, and few plausible ill-effects. We’re unlikely to know whether it achieves what it sets out to do, as Apple has predictably declined to provide any information as to what it changed.

Although disappointed at Apple’s silence, I’m not surprised. I had guessed that it had no intention to reveal fixes included in RSRs until they were rolled into the next macOS update. Because these are ‘hot’ fixes to address vulnerabilities that are either being exploited already or are considered urgent, I can see a case for temporary secrecy. As they’re easy to uninstall, unlike regular macOS updates, any resulting problems should be easy to address.

What I hadn’t expected was the mess this has brought to macOS version numbering.

When Big Sur even seemed to catch Apple’s own engineers by surprise with its new, rational version numbering system, we might have expected its cleanliness to have lasted longer than two and half years. Despite the fact that I still can’t find any official statement from Apple explaining it for users, this is how we presume macOS version numbering now works:

• The major version number, 13 in the case of macOS Ventura, increments each year with the autumn/fall upgrade.
• The minor version number, the 3 in 13.3 for the last minor release of Ventura, increments from 0 to 5 during the year of full support, then changes to 6 for the first year of security updates, and 7 for the second.
• The patch version number, the 1 in 13.3.1 for the last security update to Ventura, is only used when updates are made between scheduled minor versions, and for each security update during the two years following the end of full support.

This replaced the more chaotic scheme in which the major version number was fixed at 10, and security updates often ended up as numbered Supplemental Updates. I still dread thinking about the confusion that brought.

This new version numbering system introduced with Big Sur doesn’t provide for RSRs. One logical solution might have been to extend it to a fourth digit, making last week’s RSR 13.3.1.1. Perhaps the least appropriate would have been to introduce letters and punctuation marks other than the stop/period already used, and that’s exactly what Apple has chosen by making this first RSR 13.3.1 (a).

Although we all hope that RSRs won’t prove frequent, Apple hasn’t revealed whether they would then be incremental, with (b) including the changes in (a) in addition to its new fixes. Or would we see a Mac with both RSRs installed as having macOS 13.3.1 (ab), or (a)(b)? Are the letters intended to reset with each patch version change, so that the first RSR to 13.4 would be 13.4 (a), or are they continuous, making that 13.4 (b), assuming that no further RSRs are released for 13.3.1?

At least Apple has modified some calls that provide macOS information to accommodate this change. If you use the command tool sw_vers, then its main result now includes an additional line
ProductVersionExtra: (a)
and you can check that alone using
sw_vers -ProductVersionExtra

Similarly, those accessing SystemVersion.plist will find a new key-value pair of
<key>ProductVersionExtra</key>
<string>(a)</string>

For coding in Swift, though, extracting the RSR version is obscure. ProcessInfo.processInfo.operatingSystemVersionString returns the full string, such as “Version 13.3.1 (a)”, but the OperatingSystemVersion structure doesn’t yet have a component containing the RSR label. Until it does, developers are left parsing the full string despite the documentation for operatingSystemVersionString specifically stating “this string is not appropriate for parsing.”

That’s why, for the moment, none of my apps can tell you which RSRs are installed, except where they already give the full string. Perhaps this has come as a surprise to the engineers maintaining Foundation.

Interpretation of build numbers is more controversial, and has now reached a new height of opacity: apply this RSR to build number 22E261 and it becomes 22E772610a. Quite where the three additional digits come in remains a mystery that we can rely on Apple never to explain.

If there’s one fact of macOS that we can rely on, it’s that whenever Apple puts its version numbering into order, within a few years it will have lost all rhyme and reason.

These quibbles apart, I’m impressed with this first run with an RSR, and look forward to seeing them fly higher in the future when they only have to patch macOS on Apple silicon Macs. Congratulations to all those engineers who made it so trouble-free.