Last week was brightened up by the comments of some of those who, twenty years ago, delivered Mac OS X to us. A few proved particularly insightful, such as the tweets of @imranchaudhri, who kept a NeXT cube to hand to remind Steve Jobs that “things weren’t as good as he remembered.” Perhaps we should all have kept an old Power Mac around to remind us that previous versions of macOS also weren’t as good as we remember.

One thing I do remember repeatedly is the persistent flakiness of the Mac’s file system. Despite the promise of Mac OS X to protect the operating system from the effects of other software crashing, a lot of effort had to be put into preventing HFS+ from developing serious errors. Yet it wasn’t until Mac OS X 10.2.2 in 2002 that Apple introduced journalling to work around those problems, to a degree. Even then, after any serious crash, the cautious Mac user restarted their Mac to ensure that its file system didn’t slide steadily down the slippery slope to serious faults. Whole products like DiskWarrior were built on this lasting Achilles heel, and some days I seemed to be forever fscking around in Single-User Mode.

Just four years ago yesterday (27 March) – with iOS 10.3 – Apple introduced its replacement, APFS. Since then, this new file system has come to epitomise Apple, its strengths, endearing features, and flaws.

At the time, many Mac users wanted Apple to adopt ZFS, then something of a youthful prodigy. Although for some Mac systems it would have been far superior, Apple recognised that it was far from ideal for its biggest market, mobile consumer devices like the iPhone. In its power and flexibility there were other deep problems too. ZFS isn’t so much a file system as a way of life, a fearsome challenge to package neatly in a way that most Mac users could get the best from.

From its design conception, APFS has been intended for use on SSDs. Although it has long been clear that it will never prosper on rotating hard disks, Apple continued to sell iMacs fitted with internal hard disks until last year, knowing that they shipped with a version of macOS which can’t boot from HFS+.

APFS has many powerful features, few of which are properly documented, making it difficult if not impossible for developers to get the best from them. Perhaps the most glaring example of these are snapshots, which Apple has only recently incorporated into Time Machine backups to allow them to be stored on APFS disks. Their documentation is scant and opaque. For example, here’s an excerpt:
smeop_o
No overview available.
obj_phys_t smeop_o;

But from a developer’s point of view, there’s an even bigger problem with snapshots: Apple. A developer can’t even start writing code to work with snapshots without obtaining an ‘entitlement’ from Apple. That isn’t automatic: according to semi-official accounts, this privilege is “only being granted to backup application developers and only after very close review”. So in order to access features within APFS, developers have to be specially licensed by Apple, who won’t approve anything it doesn’t like. The effect of this is stifling.

Let’s say I want to make some major changes to my Data volume. Before doing so, I want to save a snapshot of that volume, so that in the event that something goes horribly wrong, I can quickly roll back to the state of the volume immediately prior to those changes. Despite having had snapshots in macOS for over three years, I know of no app which does just that. You can use the command tool tmutil, which makes Time Machine snapshots, but once those reach 24 hours of age, Time Machine automatically deletes them, whether or not it created them. There’s no apparent way to alter this behaviour and retain that snapshot for another day or two as the user might wish. That’s all because Apple doesn’t want you to be able to use features which it built into APFS.

My most recent example of Apple controlling what we can do with macOS is in sparse files, another jewel in the crown that is APFS. Although these were introduced to macOS over three years ago, Apple has only recently made it possible for apps to determine whether any given file is stored in sparse format. As you have come to expect, developer documentation is a sparse file in itself.

As I’ll be explaining here tomorrow morning, what we had presumed were rare exceptions are more common, because the decision as to whether a file is stored in sparse format isn’t under the direct control of apps, but is determined for them by APFS.

Neither is this confined to APFS. Speak to anyone who has been involved in the recent development of security software for macOS about obtaining Apple’s licence to use the EndpointSecurity API, or even create drivers which use DriverKit. Of course there are cogent arguments for wanting to protect Mac users from rogue software, but it demonstrates how little Apple has changed over those twenty years. Isn’t this exactly the opposite of what we all expected when Apple apparently embraced the open?