If there’s one phrase which has been held against Apple the most, it must be ‘it just works’. Of course there are plenty of times when even the most reliable doesn’t work as it should. Over the last five years on this blog, I’ve been exploring Mac things that haven’t just worked, and over the last few weeks these have focussed on Time Machine and privacy protection.
Knowing that nothing always just works should lead you to prepare for that inevitability. But in the more than thirty years that I’ve been using and developing for Macs, such preparations have been in very short supply. Until Mac OS X came along, there wasn’t even a command line where you could type inscrutable jumbles of letters in pursuit of some inner meaning to your problems.
Terminal has proved a two-edged sword, though. Many commands have grown into sprawling etceteras which, if you can master their verbs and options, only stop short of making the tea. Any command ending in -util
seems to have fallen victim to this feature agglomeration, with diskutil
even sporting its own dialect for working with APFS. It’s not surprising that so many users are genuinely afraid to open Terminal.
The pace of development at Apple now seems frenetic. New features like privacy protection appear one year, change beyond recognition the next, and continue to move so quickly that we’re trapped forever catching up. Take a year’s sabbatical by skipping a major release of macOS, and when you return you feel like Rip Van Winkle awakening. I see this when referring back to articles I published here just a year or two ago, which don’t just need a light updating now, but in many cases need rewriting from scratch, except where they cover tools provided in macOS.
For Time Machine, Apple provides no GUI tools for diagnosing or fixing problems, and a single command tool, tmutil
, which has 26 verbs to cover all the different functions shoehorned into it. The standard GUI utility for checking Time Machine errors in the unified log, Console, is unable to examine historical log entries, except by the cumbersome process of creating a logarchive. When Time Machine stops just working, Apple leaves you to your own ingenuity, and the few third-party tools available.
For privacy protection, the situation is even worse, apparently because of the fear that making it anything less than purgatory would only encourage its exploitation. GUI controls in the Privacy tab are inconsistent, confusing and deliberately misleading. Remove an app and it disappears from lists in that tab, but its settings are retained in the TCC database, ready to be automatically reinstated should any app with the same bundle ID be installed again. Its command tool, tccutil
, is the exception of the class in having only one command, to reset all, all for a specified service, and for a specified bundle ID. Its documentation doesn’t even bother to list the services which can be specified.
In the coming weeks, I am turning to look again at iCloud, another of those things that don’t always just work. Introduced more than eight years ago, and derived from previous online services dating back exactly twenty years (iTools, January 2000), over that period Apple has failed to provide users with a single utility or command tool which can be used to diagnose or fix its problems. Even Apple’s own support staff are almost invariably reduced to advising users to try turning it off and back on again. Apple’s support page for iCloud glosses over common problems such as slow or failed synchronisation.
As with Time Machine and TCC, the sub-system at the heart of privacy protection, iCloud is a prolific author of log entries. Even when your Mac appears to be idling time away, there will be long runs of dozens or even hundreds of entries detailing how it is shuffling around <private> all the time. That’s one of several challenges when using the unified log to look at iCloud: almost every important piece of information is redacted to oblivion.
Another challenge with iCloud is that what you see in the Finder or Terminal is but an elaborate illusion. What the Finder tells you is iCloud Drive/backup1/myFile.text appears in Terminal as ~/Library/Mobile Documents/com~apple~CloudDocs/backup1/myFile.text, provided that it hasn’t been evicted, in which case it will be the invisible stub file .myFile.text until it has been downloaded from iCloud again.
Someone contacted me late last year looking for a command tool which could evict and download files from iCloud. Given that I have already implemented those features in my free utilities Cirrus and Bailiff, I foolishly thought that they would be quick and simple to code, but I can’t even get a command tool to recognise any path to the user’s iCloud Drive folder.
I hope that you will join me in exploring iCloud, and in making Cirrus more useful for dealing with its problems.