Several readers have – quite rightly – questioned the information that I post here when Apple releases macOS updates and Security Updates, as to what has changed. This article explains how I arrive at my change list, and how that may not correlate with Apple’s terse release notes.

You can tell what is installed in each system update using SystHist, and in some cases this is what I use to make a first pass check through the update. Normally, Apple releases system and security updates through the App Store well before it makes standalone updaters available. Once I have installed an update, SystHist lets me see exactly what it installed.

For large updates, and where I want to inspect version Property Lists and other contents, this is not ideal, so I also download a standalone installer as soon as I can, and check through it using a package inspector: the superb Suspicious Package. That not only gives full details of every file in the update, but lets me inspect individual Property Lists using BBEdit.

Automator is a good case in point. In the pair of screenshots above, the upper shows a view of what is installed with the 10.13.4 update, and the lower 10.13.5.

The latter update installed a version of Automator which had been built on 30/05/2018, as shown by the datestamp on the executable code in the MacOS folder and the code signature. However, checking its version.plist showed that the CFBundleShortVersionString and the SourceVersion were unchanged. Bizarrely, the BuildVersion had changed from 2 (in 10.13.4) to 1 (in 10.13.5)!

My reading of this is that the source code for the executable has probably not changed at all, but it had probably been rebuilt, perhaps using a newer version of Xcode. Looking through the other installed files in 10.13.5 showed many Automator Actions were also replaced with new versions, so that is what I reported here.

APFS is more puzzling. Up to and including 10.13.4, each High Sierra update has seen a large increment in version and build numbers of the main components of APFS. The files that I watch here are those making up the apfs.kext extension, and the apfs.fs file system, which should keep in sync.

Looking at matching contents in the 10.13.4 and 10.13.5 updaters, each installed a completely new KEXT, even down to the Property Lists this time.

This is even more impressive when you look at components of the file system itself: every single file has been updated, and the apfs_invert tool has grown from 555 to 560 KB.

Checking the version Property Lists, though, is less than impressive. CFShortVersionString remains unchanged at 748.51.0, but the BuildVersion has risen from 3 to 189, and the SourceVersion has changed from 748057019… to 748067014…. My reading of this is that 10.13.5 does update APFS, but with only a few very small changes, and perhaps built on a new version of Xcode.

This is a fascinating observation in itself. It looks as if the APFS engineers virtually finished work on APFS for High Sierra back in March, and since then have surely been working hard on the new version of APFS to ship with macOS 10.14. So if you’re expecting to see any significant changes in APFS for High Sierra – such as support for Fusion Drives – you could be disappointed. But the current WWDC should reveal what the team has been working on, which will be released this coming autumn/fall in 10.14.

All this would be so much easier if Apple made the effort to publish proper release notes detailing the changes in each system update. Having established that an update does replace a given app or component, we don’t know whether this fixes or breaks anything, or is functionally identical. I believe that it’s important to know of these changes, so that when (for example) your Automator work suddenly starts to misbehave or break, you at least have an idea as to why that might be.

Think how much better it could be if Apple actually gave us clues to what its engineers had changed.