These secret preference keys might unlock experimental or abandoned features, or features that for better or worse simply didn’t make it into the official Preferences panel for that app. This might be because they were considered too complicated, or perhaps too much choice was being offered to the user (which is a Bad Thing in the world of OS X). A good example of this is the “suck” minimize windows visual effect, which has been featured in OS X since the very early days, yet isn’t accessible without using defaults write to write a secret preferences key. In System Preferences you’ll find just two visual effect choices: Genie, and Scale. Somebody at Apple clearly thought that offering a third choice would bamboozle the user. Users can write their own preference keys into a .plist file by dropping down to a Terminal window and using the defaults write command. They must specify the preferences domain for the app in question (usually in form of something like com.apple.Finder), then the key, followed by a value. This value can be a string (that is, a keyword although in rare examples it’s a complete sentence), a Boolean value (specified as 1/0 or TRUE/FALSE), or a decimal integer (usually 8-bit). You can also specify floating point values, data arrays and calendar dates, but these are much less common in the world of defaults write hacking. Generally speaking, things are turned on or off via a Boolean 1/0. Behind the Magic I know what you’re thinking. How do people find the hidden preference keys? Therein lies the magic. Lucky for you, I don’t mind playing Penn and Teller. Back in the old days finding hidden preferences was easier and involved using the strings command to search the app’s binary file for anything that was (a) human-readable, and (b) looked interesting. It was akin to fumbling around in the dark for the light switch, and it required dedication bordering on obsession to read through the output, but the rewards made it worthwhile. Sadly, Apple began encrypting OS X binaries as part of OS X security measures, so this route was closed off. Decrypting the binary and then examining it in this way didn’t work. A solution to this crisis [U2] was created by a developer called Arcticmac, who figured out a way of attaching the GNU debugger (gdb) to apps while they’re running in order to examine them for anything that took the format of a preference key. gdb comes as part of the Xcode command-line tools, which in Mountain Lion can be installed via Xcode’s Preferences dialog box. I modified the technique slightly to attach gdb to already-running app processes rather than starting them from scratch. This seems to uncover a slightly different set of results. However, even this wonderful technique is under threat: in the most recent release of Mountain Lion, Apple appears not to digitally sign gdb, limiting its access to memory locations. You can sign it yourself using Keychain Access (See these instructions [U3], although skip the part about compiling gdb from source), but one can’t help feeling the walls are closing in once again. It may well be that the move towards sandboxing apps in current and future releases PragPub January 2013 23