Macs and their applications encourage customisation, so that they work the way that you want them to. Here is a look inside those settings.

One of the first tasks when you get a new Mac is to work through its System Preferences panes and set it up in the way that you prefer. Once that is done, an essential part of getting up and running is to migrate across your many individual application and other settings, so that your working tools provide the familiar environment that you prefer. Such personalisation is a vital part of OS X, and key to your productivity and happiness.

Evolution

Classic Mac applications normally stored preference settings and other customisable information in resources, a freeform collection of special data that was often attached as a separate ‘resource fork’ to regular files. Initially these could be scattered in different locations, but eventually they were concentrated into a dedicated folder inside the System folder. A specialised resource editor, such as ResEdit, could be used to customise many details of applications, even those that were not intended to be accessible to users.

In contrast Unix, with its older lineage and minicomputer roots, relies on many different configuration files, most of which use idiosyncratic formats, but all of which are text (or processed from text). Among the most well-known are crontabs, tables of periodic events to be run using cron, the /etc/hosts file that maps between IP addresses and network names, and a legion of files with the extension .conf or .cfg that control everything from Apache to syslog. This is different again from Windows’ Registry, its central store of settings that has so often proved its greatest weakness.

During the evolution of OS X, Apple has pursued a deliberate policy of moving away from Classic resources and Unix configuration files, towards a new standard of Property Lists, almost always recognised by their .plist extension. These are written in a specialised form of XML, but since OS X 10.4 are always compressed into a binary format to save space. Prior to OS X 10.2, they used only plain text, and if your text editor does not decompress a property list automatically when opening it, you may now be confronted by binary gibberish. Thankfully all good text editors, particularly those intended for developers, such as BBEdit, should now handle this transparently.

Where to find them

The most popular locations for property lists are ~/Library/Preferences and /Library/Preferences: these contain respectively user-specific application and other settings, and those that apply to all users. However you will also find .plist files in many other folders. Particularly important are the LaunchDaemons and LaunchAgents folders located in /System/Library, /Library, and ~/Library, as those store the property lists used by launchd and launchctl to control daemons, services, and periodic tasks, in place of Unix’s old cron.

Apps which are purchased from the Mac App Store can be different. Because they must operate inside a ‘sandbox’, protecting them from the rest of your Mac, and the rest of your Mac from them, their preference settings are buried deep within ~/Library/Containers. There you will find folders named like reverse Internet domain names, such as com.acrylic.Pulp, which which the path Data/Library/Preferences should indicate where their preferences are kept. In many cases these will be links, perhaps to a property list back in ~/Library/Preferences, or elsewhere.

Property lists are also ubiquitous in application and other packages, the special folders that pose in the Finder as application and bundle files. Open any double-clickable application as a folder and you will see that it consists of a folder named Contents, within which the Info.plist file gives mandatory information for the folders and files contained within. You should never tamper with those property lists unless you know exactly what you are doing, or you could disable the application or render the bundle totally dysfunctional.

As Apple has progressively moved away from Unix configuration files to property lists, some of the traditional Unix folders such as /etc and its namesakes in other hidden parts of your startup volume have started to fill with .plist files as well as traditional .conf text documents. Anyone coming from a Unix or Linux background will find this confusing, as changing some settings is performed in the normal Unix way with a text editor, but changing others requires a bit of gentle XML. At worst you could find yourself puzzling why changes made to a now-redundant configuration file are not reflected in the service, because it relies on a property list instead.

What is in them

Open a property list up in a text or XML editor and you will see a fairly standard example of XML, prefaced by three lines establishing that it is coded in XML, citing the DTD that lays out the structure and contents of an Apple property list, and stating that it is version 1 of that document type. Then follows the content, laid out as a dictionary consisting of paired keys and data.

For each pair, the key defines the name used to refer to those data, and the matching data can be a string, true/false, various types of number including integers and reals (floating point numbers), dates, or encoded data. Any of these data can be set in an array, so an individual key could refer to a series of strings, for instance, and data and sub-keys can be nested in turn within dictionaries.

Editing property lists

If you know, or can hazard a good guess at, the meaning of various keys within a property list, you can edit the data associated with those keys as a way of altering those settings. This is simplest for datatypes that are most transparent, such as true/false, strings, and numbers, but unless you really know what you are doing, is not possible (or wise) to try this with encoded arbitrary data. Thus some preference settings that cannot be accessed through the current version of the application’s preferences dialog can be opened up, and this is exactly what is achieved by the popular third-party customisation tools.

Sometimes it is far from clear which property list controls what. A simple way of working that out is to open the folder in which you think it is stored, and set its Finder view to a list sorted by the date of last modification. Keeping one eye on that window, open the application or control panel in question, and change its preference settings in a trivial way. As soon as you do that, the appropriate property list should shoot up to the top of the list view, marking it out for your attention.

Note that the officially-recommended way of naming property lists is based on the reversed Internet domain of the software vendor. So the preference settings for the Dock are stored in ~/Library/Preferences/com.apple.dock.plist. Unfortunately not all vendors follow that rule, and some system settings are stored in property lists with names other than those expected. Sometimes trial and error is the only way to find the correct key in the appropriate file. Hence it is essential that before you start dabbling with property lists, you must have a good and complete backup, for instance that provided by Time Machine.

Some important property lists should not be edited using a text editor unless absolutely essential. For example, LaunchDaemons and LaunchAgents are far better left to the specialist editor for launchd settings, Lingon X.

Those controlled by the Server tool suite should only be manipulated through their regular interfaces in Server.app, Server Admin, and the like, in case changes conflict with those graphical tools, or your alterations are trampled over by those tools. Indeed using more than one tool to change settings in OS X Server is a complex issue, and Apple does not make it clear in the Server documentation how the different techniques affect one another.

Techniques: Application Preferences

The standard approach to setting preferences in applications is through the Preferences dialog, opened using the Preferences… command in the first application menu, although some products, principally those developed with cross-platform tools such as Java, or running under X Windows, may depart from that.

Even though substantial apps now commonly have multiple tabs in their Preferences dialog to provide access to their extensive settings, some that have become deprecated or are included for specialist use may only be accessible by editing the application’s property list.

So long as you have a passing familiarity with markup languages such as HTML or XML, opening a property list in a good text editor such as BBEdit is probably the simplest solution to direct access to all settings. BBEdit and several other apps cope transparently with the now universal binary file storage, and when you write the changed file to disk it should be cast back into that binary format.

Specialised XML editors may not be as co-operative, though. The powerful Oxygen suite, for instance, normally objects to the combination of the .plist filename extension and the text format. If you want to use Oxygen, you may need to make a copy of the property list in text format with the .xml extension. Once you have opened it, though, you have the full power of its pro tools, and can step through keys independently of data, fold away long data entries, and more.

There are several specialist property list editors available, and Apple used to provide its Property List Editor as part of Xcode. Unfortunately that standalone tool has been abandoned, and editing incorporated into the main Xcode editor. This is particularly galling now, as copies of the Property List Editor are incompatible with OS X, crashing on startup.

Fat Cat’s PlistEdit Pro (£24.46) is a dedicated property list and JSON editor which is by far the easiest and most powerful means of inspecting and changing property lists.

Tools: Tweaks and Hacks

The Finder, system features, and applications can be tweaked to do some surprising things. Some Apple products, such as Safari, ship with a hidden Develop (or Debug) menu that mixes occasionally useful and sometimes downright dangerous controls. Although you can hack property lists to open these up, the most accessible way to do this is with a third-party tool that puts a friendly front-end on this hacking.

TinkerTool and its shareware sibling TinkerTool System 2 concentrate on customisations of OS X, as well as the system maintenance features common to other ‘Swiss Army knife’ utilities. Of the two, it is TinkerTool that offers the most control over hidden preferences, covering many aspects of the Finder, Dock, bundled applications including Safari and Mail, and more.

Deeper is one of the most reliable and comprehensive tools for tweaking all manner of settings, and has individual versions which work with Tiger to El Capitan. This can open up hidden menus in most of Apple’s bundled applications, including Safari’s Develop menu, and debug for the App Store.

Koingo’s MacPilot is perhaps the most comprehensive of them all, although because of the sheer number of different tweaks that it includes, it can sometimes be slow to navigate. Even more are included in its slightly less friendly Advanced options.

Unlike some other tools, and in contrast to editing raw property lists yourself, each of these can restore safe or default settings, in the event that a tweak that you have applied becomes a liability or turns sour. This is important, as tweaks and hacks rely on undocumented features that are prone to change without notice, and the next OS X update could break them.

Updated from the original, which was first published in MacUser volume 28 issue 03, 2012.