Writing a coherent and comprehensive description of a painting is an excellent exercise not only for writing skills, but to remind yourself of the adage that a picture is worth a thousand words. Nowhere is this more appropriate than when describing graphical user interfaces such as macOS, as I reminded myself this week when trying to sort out a problem with Desktop behaviour.

That took me to Sequoia’s revised System Settings, where those for Desktop & Dock have become a farrago covering anything from the default web browser to the addition of margins to tiled windows. Although I’ve been one of System Settings’ few advocates, that section has become an example of what they shouldn’t be.

After the Finder, tools for configuring the appearance and behaviour of the interface are the most important. For many years, we had to do this through the keyhole of the fixed window size provided by System Preferences.

Many of its more complex panes had to resort to multiple tabs, here in the Network pane of 2002.

This was no easier for relatively simple panes, such as Sound, seen here in macOS 12 nearly 20 years later.

Ventura’s completely reworked System Settings were controversial, but at last provided the ability to expand panes vertically, although at that time many used floating windows to arrange discrete groups of settings in a hierarchy, such as those for Stage Manager.

Some of those used pictures, although most were illustrative rather than replacements for a thousand words, unlike the screenshot below.

Sequoia’s Desktop & Dock settings have been flattened out into a single view that’s so deep it even has to be scrolled on a Studio Display. Its sections include the Dock, Desktop, Stage Manager, Widgets, default web browser, Windows, tiling, Mission Control, keyboard shortcuts and Hot Corners, while further settings for the Desktop are controlled in Appearance and Wallpaper. Many of these are obscure unless you already use a feature, and many need further help, even for those who have been using macOS for years.

Like Desktop & Dock settings, its help page uses words exclusively rather than pictures, often doing little more than paraphrasing the text labels already shown in System Settings. Apple Support is one of many to provide a video tutorial for these settings, but those are of limited benefit when you just want to check how the options available for tabs in windows affect the appearance and behaviour of document windows, for example. Yet that would be so simple to demonstrate in three cutouts from screenshots, and so much more meaningful than the paraphrasing in Help: “Choose when you want documents to open in a tab (instead of in a new window): Never, Always or In Full Screen.”

In the last few years, Apple has devoted considerable engineering effort into enriching the macOS human interface, with Stage Manager and most recently Sequoia’s tiling feature. Even though you may not wish to use either, they do have their uses and some find them powerful.

Tiling is a case in point, as Apple seems to have decided that it should be enabled by default when you upgrade to Sequoia. That results in frustratingly changed behaviour when you drag a small window up to the top or another edge of the display, and it suddenly tiles out to cover the whole screen, without offering any Undo. Only by rummaging through System Settings will you discover that you can return that to normal by turning off Tile by dragging windows to screen edges in Desktop & Dock settings, although this has nothing to do with the Desktop or Dock.

In principle, I still believe System Settings is the right way forward, with its vertical flexibility and use of SwiftUI. But leading designs using those now come from third-party developers. It’s time for Apple to reassert its former mastery of the human interface, and realise the potential of SwiftUI by making System Settings a paragon rather than a pickle.

Over the last forty years, one of the essential virtues of the Mac’s interface has been its consistency. From the outset, Apple has ensured the Finder behaves according to a small set of rules that are readily learned, often without conscious effort. These form a grammar grounded on those of languages like English, of subject-verb-object. Select a file, do something with it, and it changes state.

Drag a file from its current folder and drop it onto another, and it’s moved or copied from one to the other. The outcome depends on context, where performing that action within the same storage volume results in the file being moved, but between folders in different volumes it’s copied instead. Folders play two roles: as enclosing elements, and as objects in their own right. Drag a folder from one place to another, and you expect its entire contents to go with it, but apply a tag to a folder, and only that folder gains the tag.

iCloud Drive has never quite conformed to the same grammar. Change its mode by enabling the Optimise Mac Storage setting and it stops behaving so consistently. Files that appear to be present turn out to lack data content, and have to be marked as evicted exceptions. Folder commands to control download and eviction depart further from established norms. Select all, and if there are more than ten items selected, Remove Downloads is no longer available in the contextual menu. Can the Finder no longer cope with certain actions when they’re applied simultaneously to more items than we have fingers?

There is a workaround, though: select just the enclosing folder, and Remove Downloads on that. If you then want to download individual items within that evicted folder, you do so by selecting them and using Download Now, which oddly doesn’t seem constrained to the same limit of ten. You can thus have a hybrid folder, with some items downloaded, others evicted, and the folder itself continues to display the icon indicating its contents remain evicted.

Now consider Sequoia’s new pinning behaviour. Pin a folder and its contents are shown as being pinned, as you’d expect. Select one or two of those individual files, though, and there’s no option offered to unpin them. The only way to do that is to unpin the whole folder, then pin individual items within that folder. But like the Remove Downloads command, that too won’t work for more than ten items at once. Move a new item inside a pinned folder, and it automatically becomes pinned, and can’t be individually unpinned as long as its enclosing folder remains pinned.

If you have a folder of 100 files, and want to pin all of them bar one, this becomes laborious. If you pin the folder, you can’t unpin that one file, so you must leave the folder unpinned and instead pin the individual files inside it, no more than ten files at time.

Against the Finder’s consistent model, eviction and downloading are well-behaved, as you can

1. select the folder, and apply the action to it,
2. select the exception(s), then apply the inverse action to them,

requiring just two selections and two actions.

On the other hand, pinning behaves inconsistently, as you must:

1. select a group of no more than ten files, apply the action to them,
2. repeat that as many times as necessary, until only the files you want pinned have been pinned.

Consistency is often taken as a mark of reliability. iCloud Drive comes from a position of lower reliability, and inconsistencies in its human interface only serve to reduce the user’s trust.

Explaining this idiosyncratic behaviour is more important still. Instead of being designed for the human, its interface has been determined by its engineering, in a step back to computers that preceded the Mac. This reflects an API that is every bit as awkward as its human interface. In common with other properties of files in iCloud Drive, developers are prevented from discovering how iCloud Drive handles them. For example, Apple makes checking whether a file is evicted as difficult as possible, as there’s no property or attribute that records that.

Pinning is similarly convoluted, and currently undocumented. When pinned individually, files are given a distinctive extended attribute, but when pinned by virtue of any of their enclosing folders being pinned, that xattr is attached not to the files, but to the folder. To check whether any given file in iCloud Drive is pinned, an app therefore has first to check whether that file has the xattr, then to traverse its path upward and look for the xattr on every folder in that path.

Thus the human interface for pinning is determined not by the Finder’s consistent grammar, but by the implementation of this feature in iCloud Drive’s virtual file system. The sooner consistency is restored, the better for the Finder and its users.