Customising your MAC : Getting your Mac and Applications running just the way you like

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 you prefer. Once that's 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 an essential part of OS X and is key to your productivity and happiness.

Classic Mac applications normally stored preference settings and other customisabie information in resources, a freeform collec­tion 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 weren't intended to be accessible to users.

By contrast, Unix, with its older lineage and minicomputer roots, relies on many dif­ferent 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 peri­odic 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 every­thing 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 configura­tion 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 version 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 doesn't decom­press a property list automatically when opening it, you may now be confronted by binary gibberish. Thankfully, all good text editors, particularly those such as BBEdit that are intended for developers should now handle this transparently.

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

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'll see that it consists of a folder named Contents, within which the Info.plist file gives mandatory information for the folders and files con­tained within. You should never tamper with those property lists unless you know exactly what you're doing because 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 tradi­tional .conf text documents. Anyone who is coming from a Unix or Linux background will find this rather 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 aren't reflected in the service, because it relies on a property list instead.

Open up a property list in a text or XML editor and you'll see a fairly standard example of XML, prefaced by three lines establishing that it's coded in XML, citing the DTD that lays out the structure and contents of an Apple property list, and stating that it's 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 that 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 this data can be set in an array, so an indi­vidual key could refer to a series of strings, for instance, and data and sub-keys can be nested in turn within dictionaries.

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

Tweaks and hacks

The Finder, system features and applications can be tweaked to do surprising things. Some Apple prod­ucts, such as Safari, ship with a hidden Debug menu that mixes occasion­ally 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 hackery.

TinkerTool (free from bresink.com) and its shareware sibling TinkerTool System (£9.95, sold in Euros at €11.90) concentrate on customisa­tion of OS X, as well as the system maintenance features common to other 'Swiss Army knife' utilities. Of the two, if s TinkerTool that offers the most control over hidden preferences, covering many aspects of the Finder, Dock, bundled applications includ­ing Safari and Mail, and more. Recent releases have included support for Lion's new features, such as behaviour with respect to restoring open win­dows when starting up applications.

 TinkerTool and its shareware System sibling specialise in giving access to OS X and Finder settings that would otherwise remain hidden

Deeper (free from Deeper Snow Leopard) is one of the most reliable and comprehensive tools for tweaking all manner of settings and works with Tiger (Deeper 1.0.7), Leopard (1.1.5), Snow Leopard (1.3.2) and Lion (1.4.2 and later). This can open up hidden menus in most of Apple's bundled applications, includ­ing Safari's Develop menu, and debug for Disk Utility, Help Viewer, Apple Remote Desktop and iCal. An alterna­tive containing an extensive collection of customisation for Lion only is Lion Tweaks (donationware from ifredrik. com/applications).

Deeper is a personalization utility for Mac OS X which allows you to enable and disable the hidden functions of the Finder, Dock, QuickTime, Safari, iTunes

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've applied becomes a liability or turns sour. This is impor­tant, as tweaks and hacks rely on undocumented features that are prone to change without notice, and the next OS X update could break them.