macOS updates serve two purposes: to fix bugs, and add or improve features. Although Apple has recently being getting better, the information it provides about updates remains skimpy to say the least.

Take this week’s Supplemental Update to macOS 10.15.6, which we’re informed fixes two bugs, the kernel zone memory leak and a problem with display colours in some of the latest iMacs following waking from sleep. Surprisingly, these take around 3 GB of update to address, which seems a tad lavish. Quite a lot of that is exactly the same set of firmware updates which were issued with the 10.15.6 update; as this Supplemental Update requires that earlier update has already been installed, it’s hard to understand the purpose of including them all over again. Then there’s a complete suite of bundled apps, almost all of which haven’t changed since 10.15.6, but which are repeated here all the same, as is the case with much of the system.

Each time that Apple updates macOS, I run a utility to scan the updated system and report version and build numbers for everything in the bundled apps folder, and for /System/Library. I then compare those new versions with those obtained following the previous update, so I can see which have changed and by how much. In this case, the end result is summarised in my article, here What has changed in the macOS 10.15.6 Supplemental Update?

This process regularly brings surprises. In the case of this Supplemental Update, there are new releases of the Books app and VoiceOver which don’t appear to related to anything mentioned by Apple, and there’s a new version of PDFKit, which provides apps with high-level support for PDF documents. Apple hasn’t seen fit to mention anything about those, or what exactly they fix or improve.

Knowing what has changed in any system update is crucial to many users, and to system administrators. I can check for changed version numbers in bundles, as they’re required to have an Info.plist file which contains version information. When it comes to command tools, though, the situation is quite different, as there’s no way to determine the version of many Mach-O files, such as the many which are part of macOS.

When I build one of my own command tools for distribution, it has to be notarized for Catalina and Big Sur. This is particularly important for tools, as without that notarization macOS could just decide to crash them, if they’re opened with a quarantine flag set. The best way to ensure that a tool notarizes properly is to attach an Info.plist file to it and add its code signature. Because Mach-O files are singular, not formed into a bundle like an app, those additions are appended to the end of the code in the Mach-O file.

Unfortunately, Apple doesn’t follow the practice which it expects of third-party developers. Although it does sign its tools, it doesn’t embed an Info.plist file, and there’s no data structure within the Mach-O format for version or build numbers (except for dylibs, which are normally placed in a bundle anyway). Cruise the tools provided in macOS, and you’ll find not one of them is shown as having a version or build number.

The traditional Unix way of discovering the version number of a command tool is to run it with the appropriate option, such as -ver or similar. To discover how to do that, you have to consult the tool’s man page, or sometimes its usage or help information, perhaps using -h. Even then there are exceptions: everyday commands like ls and mkdir seem unable to reveal any version number. Does that really mean that every version of that tool is identical?

The end result is that, if Apple doesn’t tell us in the release notes for a macOS update, not only do we not know what has been fixed or improved, but there’s no way of finding out much of what might have changed. Until, that is, we discover that it doesn’t work the way that it used to, or doesn’t work at all.

To think that there was a time when Apple provided full release notes, giving details of all significant changes to widely used tools and services, complete with version numbers. That seems hard to believe now, especially since Apple was then far smaller, and the burden of documentation relatively greater.