If you are prepared to dig deeply enough, few days pass without coming across brilliant ideas in Macs and macOS. Some of them have been allowed to flourish, but many also have infuriating snags – issues which, if addressed, would allow their brilliance to shine through.

Last week opened with a simple question: how to stop the latest version of Pages from quitting when left unattended. That led on to the murky world of global default settings and the sweeping powers of the defaults command, but left the puzzle as to why macOS should have ‘zombie’ apps at all. As if that wasn’t enough, I have been again trying to get the amazing unified log to reveal its hidden strengths, despite some bizarre limitations.

One-shots and zombies

Apple provides a lot of bundled tools with macOS, including valuable viewer apps like Preview and TextEdit. Whilst there are some who use their full features to do sophisticated things, for most of us Preview is our default image viewer, and TextEdit does the same for text and rich text documents. When you want to do serious work with those files, you’ll open them with a third-party editor, but for a quick look, the defaults are just the job.

It makes sense for macOS to tidy those apps away for us when we’re done. Leave either of them in the background with no window open, and it’s good that it quietly quits. Well, they appear to quit, but if you look carefully in Activity Monitor or bring up the Finder’s Force Quit dialog, you can see that they may linger in memory, sometimes for many hours. They’ve become zombies.

This zombie state is possibly the most complete antithesis of all good human design. The app is still there, but the user can’t directly use or quit it. The only two ways of regaining control over it are to open a document which by default will be opened by that app, or to act as if opening the app again. As zombies are removed from the Dock, App Switcher, etc., the latter is often very inconvenient.

The only conceivable benefit from this behaviour is that, if you do happen to open another document, the app ‘loads’ instantly, as it is already there, hidden and in waiting. If there’s any pressure on free memory, macOS silently quits the zombie, and that benefit vanishes as secretly as it was present.

The user can turn this behaviour off, using an undocumented global default setting, but that is all-or-nothing, and stops these apps from quitting automatically. There is no control to make them quit properly rather than hang around as zombies.

This sort of behaviour is probably most tolerable when it occurs in such one-shot viewer utilities. But when it becomes standard in major productivity apps like Pages, Numbers, and Xcode, you have to ask why macOS is being so deliberately deceptive of the user. As Apple glosses over the matter in a couple of terse lines, and then only in its developer documentation, we’ll never know its design intent.

The unified log

Apple made no secret of what it was doing when it removed the standard logging system and replaced it with Sierra’s unified log. As with so many of these ideas, the concept was brilliant, but has its share of flaws. Any log is only as good and useful as the tools which are provided to use and access them, and the features which they support.

I won’t harp on about the shortcomings of the new version of Console, which still, more than a year later, offers a derisorily small set of features. My current concern is access to the log’s data files, stored in TraceV3 format.

Apple declared at the outset that log files would use a closed format, which it was not going to document, but would provide access through the log command tool, which has also remained closed-source, so that we can’t rectify its shortcomings. Not only has log suffered several significant bugs, some of which remain to limit its use, but it lacks many functions which limit its usefulness.

This week, I have spent a lot of time working around one of those more obvious limitations. If I can’t open a TraceV3 file directly, and can only access it through log, one of the most basic questions that I need to be able to answer is the period of collection of any log file. Yet, as far as I can discover, there is no way to get log to reveal that information.

Others have much greater, apparently completely insoluble problems. Many system administrators are required to collect and analyse log information from systems on their network, for example to monitor who has logged onto each system both locally and over the network. Such information is contained within the universal log, but is buried deep. Unlike traditional Unix logs, you can’t (realistically) pipe the unified log out to a server on your local network.

The unified log has, so far, followed a path familiar to many of Apple’s brilliant ideas. It was one of the hot topics at WWDC 2016, but forgotten by 2017. Console and the log command have evolved precious little for High Sierra, and Apple seems oblivious to Sarbanes-Oxley and other audit requirements which are still left unfulfilled.

macOS is now a graveyard of other ideas which were wonderful at the time, blossomed brilliantly like orchids, and since have been largely abandoned. The tell-tale is documentation which was once written with such enthusiasm in 20xx, and revised lightly and intermittently since.

It’s an approach which works well with product design: the ‘Anglepoise’ iMac, for example was brilliant at the time, and is still one of Apple’s best concepts. In product design, though, when you move on to something different, as Apple did in late 2003, purchasers welcome the new look and innovation.

Do this with products like AppleScript, and you end up with an operating system like Gormenghast Castle, full of whole wings which are left to slowly decay for years, before finally being walled off from use.

Apple needs to finish the unified log off, extending the tools provided to support its access, mining, and use. Without them it too will go the way of so many other great ideas, until someone thinks to bring back more traditional logs.