Last Monday night I got more than a little anxious. Having predicted the release of macOS 10.14.4 update, I grew increasingly concerned that I had read the tea leaves wrong. Then Apple released the iOS update, throwing me into more doubt. Finally, just over four hours after I had expected it, down came 10.14.4.
What I hadn’t forecast or even suspected in my wildest dreams was that, for the first time in several years, probably even before El Capitan, Apple provided extensive release notes, in addition to its normal security release notes. We thus know more about what the 10.14.4 update does than any other macOS update since – well, it’s been so long I can’t even remember.
Even so, Apple could so easily have blown its own trumpet over at least three significant bugfixes which will have a very positive impact on many Mac users.
The most serious was a bug which could hang the Finder, whose only solution was to force it to restart. This was Finder’s inability to cope with previewing or opening broken Finder Aliases to folders. Having detailed it here, I was asked to enter it into Apple’s Bug Reporter, but wondered whether it would ever be fixed. It has, in 10.14.4, and I’d to thank the engineers responsible for doing so.
The next wasn’t serious in the sense that anything crashed or hung, but it made Finder windows far less usable than they should been. Thumbnails generated by QuickLook were displayed too high. The result was that new metadata displayed by Finder in Mojave and its Quick Actions usually had to be revealed by scrolling down, which was very poor design.
This too has been addressed in macOS 10.14.4, and these new features are now more accessible as a result. Once again, I’d like to thank Apple’s engineers responsible for fixing a bug which could easily have been dismissed as being cosmetic.
The third serious bug is still a bit more controversial: Font Book’s previous inability to disable fonts resident in /Library/Fonts as well as those in ~/Library/Fonts. It works fine for me here, and has definitely changed, but a couple of people have reported that they still can’t get it to work. I’m unclear why their experience should be different, so there may be work remaining in this case. I’d still like to thank the engineers who have been working on fixing this problem, though, and hope that it gets fully resolved.
What does make me feel sad, though, is that the security engineers get their moments of anonymous fame in the long list of vulnerabilities which they have addressed, but even in its extensive new release notes, Apple hasn’t acknowledged the achievements of its other engineers who have fixed the bugs that I’ve mentioned above, or the many others which I suspect 10.14.4 also addresses.
There’s been a lot of discussion about Bug Reporter and Apple’s internal pressures, and one thing is clear: being an engineer at Apple isn’t conducive to fixing bugs. Yet it’s a very important activity for many users, and for the long-term health of both Apple and its operating systems. It’s all too easy to be negatively critical of Apple, but it’s just as important to point out when it has done well – both carrot and stick.
macOS 10.14.4 thus marks two important milestones: Apple has returned to providing us with detailed release notes, albethey lacking a list of the main bugs which are fixed, and Apple has been devoting resources to fixing the bugs in macOS rather than just endlessly adding new features.
However, all with macOS isn’t sweetness and light. One of the major internal changes brought with 10.14.4 is that Swift ‘glue’ libraries – runtime support which enables Swift code to work with frameworks – are now built into macOS. An odd side-effect of this is that command tools built using Xcode 10.2 won’t run on any previous version of macOS, including 10.14.3, unless the user (or the command tool’s installer) installs the Swift 5 Runtime Support for Command Tools package from here.
This not only applies to dedicated command tools, but to those embedded in app bundles and other locations. Apple has documented this quite sketchily in the release notes for Swift 5, but hasn’t, as far as I can see, detailed this for regular macOS users.
I can see Xcode 10.2 bringing significant grief with tools crashing on launch with errors reporting
dyld: Library not loaded, which is going to mystify many users who aren’t intimately familiar with such details. So the 10.14.4 update, in conjunction with Swift 5 in Xcode 10.2, is making life significantly more complex for anyone using command tools. This surely needs clear documentation aimed at users.