Last Week on My Mac: Working together, not apart

Back in the early 1990s, I wrote my own versioning system for Classic Mac OS. At that time I was developing CAD/CAM software primarily aimed at sailmakers who were using their Macs to drive huge laser-cutting systems to cut rolls of expensive fabrics and assemble them into sails for yachts. There were three main apps: Loft, used to convert a sail design into its constituent panels, Panellist for editing individual panels, and ShapeFit to pack panels into queues and cut them. My customers wanted Panellist to save previous versions of each panel, to make it easier to iteratively adjust them for production.

My solution was to save previous versions as resources, the predecessor of what are now extended attributes.* Each time the user saved a panel, the current version was automatically written as a new resource to the panel document. To prevent these resources from growing indefinitely, Panellist kept only the last 10 or 20 versions, automatically removing the oldest with each save.

A decade later, Apple introduced a not dissimilar feature in OS X 10.7 Lion, although this pooled all the versions saved for documents in each volume into a hidden folder .DocumentRevisions-V100, and provided an interface similar to that of Time Machine for accessing them through the app used to create those versions. Seven years later, in 2018, I realised the limitations of Apple’s approach, couldn’t find a utility that could manage versions outside the apps that created them, so wrote my own, Revisionist, first offered as a beta-release here six years ago.

It only took me a couple of months to discover that, at that time, versions didn’t seem to be respected by iCloud Drive, but by that autumn they appeared to have changed. Since then, I have periodically revisited versions, and how they’re handled by iCloud Drive. That has become a sorry saga of missed opportunities, leading up to the current confusion.

The best way I can explain this is with two models: a user who edits shared documents on external storage that’s moved between their Macs, and another who does the same using documents shared in iCloud Drive.

Because the version database is stored on each volume, covering documents edited on that volume, the user with the shared external drive enjoys versions saved on each of their Macs wherever they go, provided they don’t move the documents to another volume, and separate them from their saved versions, which would then be deleted rather than transferred.

The user sharing their documents in iCloud Drive has different problems. As iCloud Drive is effectively an extension of their Data volume, each Mac they connect to their iCloud Drive has its own local versions, saved in the hidden folder .DocumentRevisions-V100 on that Mac’s Data volume. Because those versions are local and not shared, each Mac can only see the versions that it saved.

The obvious conclusion is that, if you’re going to work on the same documents across different Macs, you’re better doing so using a shared external drive than using iCloud Drive.

Add an iPad or two, and this changes for the worse. To my surprise, when used on an iPad, apps like Pages can’t access versions saved to either internal or external storage. The only versions that an iPad can access are those for documents edited and kept in iCloud Drive. So, if you want to work collaboratively across both platforms, whatever you choose, at least one copy of Pages will be unable to access versions saved by Pages on another platform. And the option that provides most restrictive access to saved versions is iCloud Drive, the one Apple wants you to use to share your documents.

This is the same Apple that has invested heavily in bringing Continuity features to Macs and all its devices, so you can share displays, input devices, even clipboards between them. But you can’t share document versions.

* To be more accurate, in the modern system of extended attributes, what was then a resource fork of a file is now an extended attribute containing the contents of that resource fork, itself containing a set of named resources.