iCloud Drive is steadily becoming central for many Mac and iOS users. It makes good sense: relatively seamless integration of all your Apple products almost wherever you go. If you’ve got half an hour between meetings, why not do a little more work on tomorrow’s presentation, or next week’s report, even though you’ve only got your iPad, and not your Mac?

From its outset, though, we have learned that cloud connections aren’t as reliable as USB, Thunderbolt, or even our own local networks. Cloud suppliers, like Apple, have built in plenty of mechanisms to accommodate that. What we see as remote extensions to the Finder and local SQLite databases like Notes are in fact vast distributed databases using tools with exotic names like Hadoop.

But no matter how clever those databases are, what most determines the user experience of iCloud is its support in macOS (and iOS) and its apps. Apple has had plenty of time now to get this right, but still has a long way to go before working on documents shared over iCloud comes close to working locally.

My case in point is versioning. Although for some this is a feature seldom used, it becomes particularly valuable when you’re working in the cloud using two or more systems to access your documents. Versioning is the cloud equivalent of Undo, at its best when you’re working in short bouts but require access to that document’s editing history.

Yesterday I pointed out two significant problems with versions in iCloud shared documents, that result in patchy version histories and duplication. Today I add a third, of inefficiency.

Patchy version histories result from a shocking bug in the way that macOS manages versions in iCloud. Each time that you save a new version during the editing process, that new version is packaged up for dispatch to the versions managed by iCloud Drive. Logically, macOS would then synchronise up those packages in the order in which they are created, so storing a complete version history remotely.

What actually happens is that the queue is disrupted when a new version is created, and may cancel the up-synchronisation of a version package already in the queue. Locally-stored versions might run 1, 2, 3, but if version 3 is saved and ready for iCloud before version 2 has been handled, versions available from iCloud Drive might only be 1 and 3.

Edit a document several times on different systems, and the versions available from iCloud can readily be very different from the union of those held in local version storage.

This is compounded by duplication of versions. As neither local nor iCloud version management are ordinarly controllable, the standard configuration for macOS is to add new versions to both the local version store and that in iCloud. When you view or retrieve those versions using the Browse All Versions… command, you are offered all locally-stored versions, and all those found in iCloud, delivering two copies of most.

These are exemplified in two contrasting lists of available versions of a Pages document stored on iCloud Drive, once all have been downloaded locally. Above are 7 different in a total of 14 saved versions visible from the document owner and creator, and below is the very different simultaneous view of the same document from another system, which can only find 5 different in a total of 6 saved versions, and lacks one completely.

Many of Apple’s documents, and document libraries, are now packages containing their content in a hierarchy of files. When stored on an APFS volume, this has the prospect of highly efficient storage, as different copies of a packaged document can contain cloned files which are common to previous versions, in effect hard links to common data.

Let’s say that a Pages document contains an embedded image MyPic.jpeg. The first time that you save that document as MyDoc.pages, that image is stored on the disk as part of the package contents. The next version, which doesn’t change the content of MyPic.jpeg, only needs to refer to that original image, thus minimising the storage required for that new version.

Although macOS may use a cloning scheme when synchronising versions up to iCloud, it certainly doesn’t do this when retrieving them. When you Browse All Versions… on a different system, most or all versions will still be stored in iCloud and await downloading before they can be previewed or used. When tested here with a Pages document of about 35 MB size, every version downloaded was a complete and separate copy of the document, and occupied the same size even though most of its contents duplicated those of other versions of that document.

For a 35 MB Pages document, that isn’t too much of a problem; scale that up to a 500 MB Keynote presentation, and browsing iCloud versions becomes a slow and tedious process of downloading a great many identical files.

One promising feature noticed during these tests has been that current sharing of version history is backdated: one Pages document used contained an old version dating back to early 2016; that original version was also copied to the iCloud version store, and thereby made accessible to other systems.

In its present form, versions for documents in iCloud Drive is little better than an alpha-quality demonstration. If Apple wants to make this type of feature a selling point of its products, it needs to address these shortcomings.

Furthermore, Apple needs to discover why some attempts to sync up to iCloud only complete after absurdly long periods. When performing these tests, I wanted to look at versioning on a 500 MB Keynote presentation. Despite intensive transfer of network packets for over an hour, I couldn’t get iCloud Drive to sync that document up. And that continues to be quite general experience among many iCloud users.