Regular visitors will know that, as soon as I can after each update to the current version of macOS, I post an article detailing, as far as I can, the changes brought in that update. My recent accounts of Big Sur versions 11.2.1 and 11.2.2 have prompted several questions. This article tries to explain what I do, and why I think it’s important for you.

Knowing what’s changed

Wind the clock back to the early days of Mac OS X, and Apple used to provide extensive release notes with each update, listing all the significant changes, including those to fix security vulnerabilities. It’s now a good few years since users have been provided with such detail, although where appropriate, Apple does provide a detailed account of security fixes. I’m unsure as to whether it considers other changes too unimportant to mention, or that we aren’t interested in them.

If you want to look through lists of security updates, this page has links to them all. You’ll notice that Big Sur 11.2.1 (and concomitant Security Updates) has a page in which there are three items listed, including the famous sudo vulnerability. There is no such page listing fixes in 11.2.2.

Apple’s matching page which details other changes in each update to Big Sur is here. You’ll notice that there’s a single item given for 11.2.1, and (at the time of writing) no entry at all for 11.2.2. Indeed, in my own analyses of those two updates, remarkably little had changed in them, despite their large sizes, particularly for M1 models.

Look back, though, at my analysis of 11.2, and you’ll see a major mismatch between the six items listed by Apple, and the changes that I found in version and build numbers. For example, Apple didn’t mention any changes in Disk Utility, one of the key tools for every Mac user, yet its version number had risen from 20.0 to 20.1, indicating that changes were more extensive than a little cosmetic improvement. Similarly with Migration Assistant, Software Update, several kernel extensions, and even SQLite, which had all changed versions too.

Why do you need to know?

New builds and versions, sometimes in frameworks and other code on which apps and tools are dependent, can fix bugs, or introduce new ones. One of the first questions you must ask after any macOS update appears to solve a problem or cause a new one, is whether that’s the result of what changed in the update. If you don’t know what changed, then working round problems is like walking round wearing a blindfold.

This is most critical for those who support many Mac users, such as sysadmins, but applies on a smaller scale to everyone who uses a Mac. Knowing what has changed in an update tells you whether that bug in Mail is likely to have been fixed, or whether a new problem that’s appeared in QuickLook thumbnails is the result of an updated importer.

There’s an excellent example of this in the current inability of Spotlight to search the content of RTF files. Although some of us first noticed some problems a while ago, it’s only by knowing when the bug appears to have been introduced that we can understand that Spotlight indexes made prior to Catalina 10.15.6 should retain their searchable content until they’re re-indexed.

How do I know?

Following careful discussions some years ago, when I first started reporting on what appeared to have changed in updates, we settled on two robust criteria: the version and build numbers. These are supplied for bundles like apps, extensions, frameworks and more, in the Info.plist file which they’re required to have. Although there’s considerable variation in format, in general Apple’s engineers ensure that build and version numbers change when bundles change. They don’t of course tell us what has changed within that bundle, but when Disk Utility is bumped from version 20.0 to 20.1, it’s almost certain that there have been significant changes which affect its function.

Unfortunately, a lot of macOS doesn’t consist of bundles with their helpful information. Build and version numbers can be added to single-file executable code (Mach-O) files and even scripts, but this is very seldom done in macOS. Some command tools like sudo have an option such as -v which reveals their version number when they’re asked, but in general those developed by Apple don’t. I have tried searching standard folders which are rich in command tools, and drawn a blank for almost every one.

The only other information is circumstantial. Just because a datestamp on a file is recent doesn’t mean that anything significant has changed in its code, and similarly with file sizes. In any case, with Big Sur’s sealed System volume, Apple has standardised on a single datestamp, so every file within that now claims that it was created and modified on 1 January 2020. That doesn’t help.

Each time that Apple releases an update to the current version of macOS, I install it on an Intel Mac, and an M1 model, and obtain a list of all the bundle build and version numbers for two key folders: /System/Applications, which contains the bundled apps, and /System/Library, which contains almost all the other immutable bundles that make up macOS. I then compare the lists with those for the previous version, and summarise changes in my article explaining what has changed in that update.

Hopefully this explains why I do this, how I obtain the information, and why I think it’s so important. I’m looking forward to checking Big Sur 11.3, and hope again to provide fuller information to help you.