One thing which surprises me when answering questions from Mac users is the number of people who have more than one Mac. It’s quite common for questions to run something like: I’ve got this problem on one of my Macs, but it doesn’t affect the other [one/two/more]. There are also many of us who end up working on any of several different Macs, because we travel between different locations.

In those circumstances, unless you’re using a well-managed network, keeping track of the many preferences and settings for your work apps can range between the hard, and the just-gave-up-trying.

Better and more sophisticated apps give you leeway to perform extensive customisation or personalisation, to the point where the app assumes a persona. Switch to using the same app on a colleague’s Mac and it might work very differently to yours. The best apps might also let you save compound window layouts and toolsets, so that you can switch between various flavours according to the type of work that you are doing.

Underneath all this, those apps are storing all your settings in property list files within your Home Library folder. If you’re lucky, they’ll be in plain view in the Preferences folder there, but so many now work within an app sandbox and use files stored deep down inside their container, in the Containers folder. Somewhere in amongst the many folders and aliases there.

This is all fine and dandy when you use but a single Mac, or your software environment is lovingly cared for by an expert sysadmin. But for my questioners with a couple of MacBook Pros and an iMac, or for the mobile worker, it becomes a real mess. The best that they can do is copy across all the app’s preference files, assuming that they can discover where they’re hiding, and exactly which file(s) are required.

Preference settings and other app-specific settings can of course be shared in iCloud, but this seems exceptional outside Apple’s apps. That’s another puzzle, because while Apple recommends that third-parties can use iCloud for small amounts of essential shared data, Apple’s own apps – Photos, Mail, Contacts, Calendars, Keychain, and more – seem to share almost unlimited amounts of their data, provided that your iCloud account has the space.

We’re also back to the battle between the user and cfprefsd managing defaults/preferences/settings again. If you have run an app since your Mac was last started up, then replace its preferences file, unless you log out and back in (or restart), there’s a good chance that the replacement preferences file will be overruled and overwritten by cfprefsd. They might be my personal preferences in my Home folder, but macOS knows how best to manage them, not me.

My case in point is my free log browser, Consolation. For version 3, I wanted to let the user do almost anything possible with their logs – to obtain extracts using predicates of maximum complexity within the constraints of the log show command, to lay them out in exactly the way that they want, and to search their messages using full-powered regular expressions. But to build in a complete system for editing each of those was inefficient.

Examining Apple’s documentation only convinces me that it suffers a desperate shortage of technical authors: its Runtime Configuration Guidelines were last revised in 2009, and Preferences and Settings Programming Guide was last revised in 2013, in the transition from OS X 10.8 Mountain Lion to 10.9 Mavericks.

The most sensible approach seemed to be to let the user export their customisations in a property list file, and to be able to import them at will. Importation then posed another question: should imported customisations replace all current settings, or add to them? The best answer is to let the user choose, which empowers them further.

These property lists, even though they may look like preferences files, operate outside the NSUserDefaults and cfprefsd system, which would render them unusable. I already have a folder of customisation property list files which I can use to change Consolation’s flavour, and whole persona, whenever I wish, even in mid-flight. The thought of letting those loose in ‘domains’ under the management of cfprefsd is chilling, the more so as Apple nowhere documents exactly how those settings would be managed for the user, nor provides any controls over that management.

The end result is an app which is now infinitely extensible and customisable, and what is more, the user remains in complete control of their own customisations. They can store their custom settings in iCloud, and other shared storage schemes such as DropBox, or move them around on a memory sticks.

I think that this is an approach which other apps could and should follow, and one which could usefully be given its own interface class – assuming that there isn’t one already buried somewhere in macOS. In fact, doesn’t it remind you of what OS X was like before Apple decided that it should manage our preferences for us?