How does iCloud work? Plus a new version of Cirrus

Even if you don’t sign into your Mac using an Apple ID, it still connects to iCloud so long as it has an open internet connection. For many of us, though, iCloud and iCloud Drive are essential features of using Macs and Apple’s devices. They make it easy to share passwords, photos, documents we’re working on, and much more. This article explains the basics of how iCloud and particularly iCloud Drive now work, and provides a new version of my free utility Cirrus to help you investigate them.

iCloud is descended from a long series of features in older versions of Mac OS, going back to iTools in January 2000. It’s currently divided into two main functional services: CloudKit to handle databases, and iCloud Drive for storage of files. These appear to be implemented in the same vast distributed databases served by Apple’s own data centres and those of third-parties including Amazon’s AWS. macOS also includes some specialist tasks relying on iCloud such as the Find My service, and App Store apps are able to synchronise small shared dictionaries of key-value pairs such as preferences in an Ubiquitous Key-Value store.

CloudKit

This supports structured cloud-based databases, including the synchronisation of Core Data containers through Persistent CloudKit Container private databases. This is exceedingly complex, and uses the com.apple.cloudkit sub-system and the cloudd service in macOS.

When used to synchronise a Core Data container for an app’s database, changes to a local container are scheduled to be synchronised up to iCloud by the DAS-CTS dispatch system, and that’s performed in the background when conditions allow. Because of the time elapsed between the app making a change and it being synchronised up by CloudKit, tracing entries in the log can be difficult.

CloudKit is used extensively by bundled apps like Notes, by many third-party apps that keep their data in iCloud so it can be shared between different Macs and devices, and more. It also hosts some important system services for macOS, including the online app notarization database, one of the most important iCloud services to work without an Apple ID.

CloudKit services are controlled for macOS features in iCloud settings, in System Settings > [Apple ID] > iCloud. Third-party apps may place their control in the app’s settings, but they’re also combined with iCloud Drive access in the iCloud Drive settings: open those and click on the Apps syncing to iCloud Drive item at the foot of that dialog to see a full list and control their access to iCloud as a whole.

icloudintro1

icloudintro2

iCloud Drive

In contrast to CloudKit, iCloud Drive is far easier to deal with, and to understand, as it’s largely in the control of the user, and its actions are readily observable. When you copy or move a file to your Mac’s iCloud Drive, the com.apple.clouddocs sub-system and bird service upload that file to your iCloud Drive, then synchronise the information held in iCloud with that on each connected Mac and device.

Another sub-system in macOS is responsible for dividing blobs of data into the chunks used in iCloud storage: com.apple.mmcs reveals its ancient origins in its name of MobileMe Chunk Storage, or MMCS.

iCloud Drive local paths

If you’re using iCloud Drive without putting Desktop & Documents Folders into iCloud, your own iCloud Drive folders will be found in ~/Library/Mobile Documents/com~apple~CloudDocs. This roughly corresponds to the top level of iCloud Drive as seen in the Finder. However, macOS adds other folders that are actually located in ~/Library/Mobile Documents/.

If you have enabled Desktop & Documents Folders with iCloud Drive, those folders don’t include your Documents and Desktop folders. There are several ways to locate them, including following the symlink placed in ~/Library/Mobile Documents/com~apple~CloudDocs (useful for Documents only, as no symlink is created for the Desktop), or by opening those folders from the top level of your Home folder. This can become extremely confusing because of discrepancies between what’s shown in the Finder, and what can be seen elsewhere. This is all part of the illusion created by macOS with iCloud Drive.

iCloud Drive controls

There are four controls available for iCloud Drive, in addition to that giving access to third-party apps (above):

  • iCloud Drive switch, in iCloud > iCloud Drive;
  • Desktop & Documents Folders switch, immediately below that;
  • Optimise Mac Storage switch, at the top of the main iCloud settings;
  • the Finder’s contextual menu for the contents of iCloud Drive, allowing you to Download Now or Remove Download.

Storing the whole of the contents of the Desktop & Documents folders is an attractive solution for those with limited space for their Home folders, particularly when used in combination with Optimise Mac Storage. It has two potential drawbacks, though. It’s easy for the total stored in the two folders to exceed available free space, which prevents the contents from being properly backed up and can cause a crisis should you need to download most or all of what’s stored in iCloud Drive. Should you want to turn off Desktop & Documents Folders, you must plan that carefully to cope with the resulting removal of local files.

Enabling Optimise Mac Storage lets macOS determine which files in iCloud Drive will be stored locally as well (downloaded), and which will be removed from local storage and only kept in iCloud (evicted). While the wording displayed might suggest that eviction is only performed when local free space becomes low, that isn’t accurate, and macOS may decide to evict files that haven’t been accessed for a long while, and others seemingly at random.

Immediately after a file is added to iCloud Drive, it’s both stored locally and kept in sync with the copy uploaded to iCloud storage. When that file is evicted, a stub file is kept in its local place, whose name is identical with the addition of a prefix of a stop/period. The stub file is very small by comparison, and because its name starts with a stop/period, the stub file itself is hidden, although the Finder shows the original file name with an evicted icon next to it. Stub files also retain the extended attributes of the original file, together with the special extended attribute of type com.apple.icloud.itemName containing the name of the original file. Evicted files behave differently, as they can’t be searched by Spotlight, and can’t be backed up by Time Machine, as I’ll discuss in future articles. They also lack a QuickLook preview.

Logs

Custom log browsers for iCloud are available in Cirrus and Mints. These distinguish between:

  • com.apple.clouddocs reporting transactions for iCloud Drive,
  • com.apple.cloudkit reporting transactions for CloudKit,
  • com.apple.mmcs chunking data for iCloud storage,
  • cloudd and bird, as the services for CloudKit and iCloud Drive respectively.

You can obtain a similar extract using the predicate
subsystem == "com.apple.clouddocs" OR subsystem == "com.apple.cloudkit" OR subsystem == "com.apple.mmcs" OR processImagePath CONTAINS[c] "cloudd" OR processImagePath CONTAINS[c] "bird" OR processID = 0
with log show.

Cirrus

One of the problems with using the Finder to try to understand what’s going on with iCloud Drive is that it has a habit of changing the status of documents there. If you open a folder of evicted documents in the Finder, macOS starts downloading some or all of them if it can. One way to work around this is to use the custom browser built into my free utility Cirrus, which also features a simple test of uploading a 1 MB file to iCloud Drive.

I’m pleased to provide a new version of Cirrus, 1.13, which is now fully updated to work with recent versions of macOS including Sonoma. It’s available from here: cirrus113
from Downloads above, from its Product Page, and via its auto-update mechanism.

Its menu bar companion Bailiff is no longer as useful as it has been in the past, now that you can evict items in the Finder. I will be assessing it further to see if there is any value in updating it as well.