Tutorial: Preferences Files: The Complete Story

Tutorial: Preferences Files: The Complete Story

Ted Landau

Of all the "under the hood" components of Mac OS X, my personal favorite is preferences files. Why? For starters, they are important. They potentially affect every application you use, from the Finder to obscure utilities. Second, there are significant and well-defined troubleshooting issues regarding preferences files, that every user should know about. Third, there are the numerous "hidden" preferences settings that unlock useful and sometimes "fun" features of applications that you would otherwise never know about. And finally, compared to the intricacies of UNIX, preferences files are a fairly easy component to master.

So, for the benefit of those of you not yet initiated into the world of preferences files, or if you just want to expand the horizons of your knowledge, I offer this tutorial. The topic is so big that it will take several of these articles to cover it; three or four at least. This first one (which combines Parts I and II) introduces the basics.

PART I: What and where are preferences files?

Q. What exactly are preferences files?

A. Almost every Mac OS X application allows you to customize its settings. This is typically done by selecting the Preferences command from the application's "application" menu. Let's use TextEdit as an example. Go to the menu named TextEdit. The second item is "Preferences." Select it. The window that opens has two tabs" "New Document" and "Open and Save." In each case, you can make changes to TextEdit's default settings. For example, you can change the default fonts of Monaco 10 and Helvetica 12 to whatever else you may prefer. You can similarly decide whether or not a .txt extension should be automatically appended to the names of plain text files when you save them. And so on.

The point here is that when you make these preferences changes, they are "remembered." That is, if you quit and relaunch the application (even if you shut down and restart your Mac), the changes you made will still be in effect. Not only that, if you have multiple user accounts on your Mac, each user has their own preferences settings. This means that any changes you make will not affect the settings for any other userâ??and vice versa. In brief, each user can customize the settings for each application to suit their own preferences (hence the name).

How does Mac OS X accomplish this feat? It does so by maintaining a preferences file for each application. Any changes a user makes in the Preferences dialog are stored in the application's preferences file. The application checks this file on launch to determine what settings to use. Further, each user maintains a separate preferences file that is only in effect when that user is logged in. That's how each user can have their own settings.

As we will explore more later on, these files also may store settings that go beyond what you set in Preferences dialogs. For example, it may store the last time you opened the application or the size of its window (assuming you resized the window from its default setting).

Q. What are these preferences files named in the Finder?

A. Typically, a preferences file is named after the application that links to it. The name also ends in ".plist"â??to indicate that it is a "preferences list" file. For example, for TextEdit, the preferences file is called: com.apple.TextEdit.plist. The beginning part of the name ("com.apple") indicates the vendor that created the application; this insures that no two preferences files will have the exact same name. That is, even if another company creates a program and names it TextEdit, its .plist file will not contain the word "apple" so their should be no confusion as to which .plist file is which.

Q. Where are these preferences files located?

A. Most of the preferences files that we will be talking about are stored in a folder named (appropriately enough) Preferences, and located in the Library folder of your home directory. This, hammering home this point, is how each user can have their own unique preferences file for TextEdit. For example, the full path to TextEdit preferences file in my home directory is /Users/landau/Library/Preferences/com.apple.TextEdit.plist.

To help you visualize exactly how all of this works, try this:


  1. 1. Go to ~/Library/Preferences and locate the com.Apple.TextEdit.plist file. To do so most easily, go to the Preferences folder; then type "TextEdit" in the Search text box at the top of the window. The results should show just one file: com.apple.TextEdit.plist.
  2. Note the file's modification date.
  3. Launch TextEdit and access its Preferences dialog.
  4. Make a change to any Preferences setting. Quit TextEdit (probably not necessary, but do it just to be sure).
  5. Now recheck the .plist file's modification date: it should have changed to the current time (or a minute or so ago). This reflects the fact the change you just made in the Preferences dialog was in fact recorded in the now updated .plist file!

Figure 1. The com.apple.TextEdit.plist file, highlighted in the Finder display of a Preferences folder.

Q. Okay. I just looked in my Preferences folder and, as you predicted, I found dozens of .plist files there. But I also found numerous files (and even some folders) that do not follow the naming convention that you just described. What gives with them?

A. True enough. For example, if you have AppleWorks or Microsoft Office installed, you will have AppleWorks and Microsoft folders in your Preferences folder. Inside each folder will be numerous files that do not have .plist in their name. There will also likely be files at the root level of the Preferences folder that do not conform to the .plist naming format. Often this is because the applications that use these nonconforming files were originally developed for Mac OS 9 and have been updated for Mac OS X. As such, they may still use the preferences format used in Mac OS 9. Or they may be cross-platform applications, and employ a preferences mechanism that is similar to what is used in Windows. Or they may simply choose to use their own unique preferences format, bypassing what Apple and Mac OS X have provided. In most cases, these non-conforming preferences files still get stored in your Preferences folder.

For this tutorial, however, we will only be looking at "true" .plist files.

Q. Are there other Preferences folders besides the one in each user's Home directory?

A. Yes. Most important, there is one in the main Library folder: /Library/Preferences. This folder is used to store .plist files that remain constant for all users. For example, it may contain the settings for how the computer is connected to the Internet. Or it may store the last time an application was open, regardless of the user who opened it. As is true for most files in the /Library folder, these .plist files can only be modified by administrators.

In some cases, an application may have a .plist file in both levels of Library folders; one for system-wide changes, another for changes unique to each user.

Figure 2. The com.apple.SoftwareUpdate.plist file in the ~ /Library/Preferences folder (top) and the /Library/Preferences folder (bottom).

Q. Are there .plist files that are not linked just to a specific application?

A. Yup. For one example, as I just indicated, there is a preferences file for your Network settings. These are largely determined by the settings you create in the Network System Preferences pane, rather than a typical application.

Q. Are there .plist files beyond those in Preferences folders?

A. Once again, the answer is yes. This basic .plist format pops up in numerous other components of Mac OS X. Of particular interest, there are two .plist files inside almost every application package: Info.plist and Version.plist. There is also a SystemVersion.plist file in /System/Library/CoreServices. These files have nothing to do with settings made from Preferences dialogs. We will touch on the function of these files near the end of this series of tutorials.

For now, our main focus remains on the basic .plist files found in ~/Library/Preferences and (to a lesser extent) in /Library/Preferences.

PART II: Viewing Preferences files

Q. Okay. I'm in. Now I would like to actually view the content of a preferences file. How do I do it?

A. Prior to Mac OS X 10.4, preferences files were simply text files. As such, they could be opened in an text editor, such as the TextEdit application that comes with Mac OS X or third-party software such as TextWrangler. Double-clicking a .plist file would not automatically launch any of these text editors. However, if you dragged a .plist file to the desired text editor's icon, it would open in that application.

This has changed a bit in Tiger. While some .plist files may still be ordinary text files, most (especially those created by Apple) have been converted to a binary format. Supposedly, because binary files are smaller and can be read by the OS software more efficiently than text files, this change was done to speed up response times.

Technically, these binary files can still be opened in a text editor. But the text will be largely unreadable. It will include non-ASCII characters, and will be in a format that is difficult to interpret and even more difficult to figure out how to edit.

Fortunately, there are alternatives to text editors for working with these filesâ??including one you already have (assuming you are using Tiger or a Mac purchased in the last couple of years): Property List Editor (PLE).

Property List Editor is an application that gets installed if and when you install Apple's Developer software. The installer package for this software can be found in the Xcode Tools folder on the Tiger DVD or in the Installers folder (inside the Applications folder) of your Mac's pre-installed software. Once installed, you will have a folder named Developer at the root level of your drive. Inside this folder, navigate down to the Applications>Utilities folder. Here is where you will find Property List Editor. This is the default application for .plist files, which means that if you double-click a .plist file, it should now automatically launch Property List Editor and open. [See Figure 2 for an example of how .plist files look when opened in PLE.]

The first notable advantage of using Property List Editor over a text editor is that it works equally well with both the older text format of .plist files and the newer binary format. In fact, from the display of a .plist file in PLE, you could not tell whether you had opened a binary-formatted file or a text file. Second, PLE uses a graphic format to display the contents of .plist files that makes it easy to identify and modify the file's editable components yet also makes it almost impossible to alter the basic syntax of the file (which might otherwise result in a "corrupted" file) because it hides the syntax tags from the user.

Third-party developers have thrown their hat in the ring with applications designed to compete with Property List Editor. Two of my favorites are Pref Setter and PlistEdit Pro. They both offer two worthwhile features not included with Property List Editor:

  • They can generate a list of all .plist files in your Preferences folders. This makes it easy to locate and open the file you want, without having to navigate to the file via the Finder or the Open dialog.

  • They allow you to copy and paste text, including entire properties (key, class and value), from one part of a .plist file to another; Property List Editor inexplicably does not allow you to do this.

These applications, of course, have also been updated to work with both binary- and text-formatted .plist files.

Q. What if I would still prefer to use a text editor to view .plist files? Isn't there some way I can convert the binary files to a readable format?

A. Yes, there is. What you can do is use Property List Editor to convert the binary file into a format that displays properly in a text editor. To do so, open the desired file in PLE and select Save As... From the sheet that drops down, access the File Format pop-up menu. From the items in the menu, select XML Property List File. Now save the file. After this, it will open in a text editor in the same readable format used by all .plist files prior to Tiger.

These XML formatted files will also work just fine as active .plist files.

As an alternative, you could instead save the file as an ASCII Property List File. With this format, you essentially convert the binary text to readable text, but without the addition of the XML syntax. It's a much more compact format than XML. But there is a downside: at least in my experience, these files will not work correctly as active .plist files.

Figure 3. A com.apple.SoftwareUpdate.plist file, viewed in TextEdit as a binary file (top); as an ASCII formatted file (middle); and as an XML-formatted file (bottom).

Q. You just mentioned XML format. What is that exactly?

A. XML is a markup language, similar to HTML (the basic language of Web pages). It is not necessary to understand the details of how XML works in order to work with .plist files. Suffice it to say that most items (or properties, as they may be called) in .plist files have three XML components: a key (which is the name of the property), a class (which defines the type of property, such as whether it is a text string of a Boolean value), and the value itself (for a Boolean property, for example, the value would be either True or False).

PLE graphically represents each of these three components, making it very easy to see the structure of the file and edit any desired component.

Q. Property List Editor does not offer an option to save files as binary files. What if I have an XML formatted .plist file that I want to convert to binary; can I do it?

A. Yes. Probably the simplest way is to use Terminal (the application for working with UNIX in Mac OS X), via a command called plutil. To do so, you would type the following:

plutil -convert format plist_file_pathname

For format, use either xml1 to convert a binary file to XML format, or binary1, to convert an XML file to binary format. The simplest way to get the needed pathname is to add a space after entering the format and then drag the icon for the file to the Terminal window. The pathname will be automatically added. Then, just press return and the job is done. For example, a completed command to convert an XML formatted file to binary format might look like this:

plutil -convert binary1 /Users/landau/Library/Preferences/com.adobe.acrobat.reader.plist

Q. Speaking of Terminal, can I use Terminal to work with .plist files (view and edit their content), instead of using PLE or similar utilities?

A. But of course. The command that does this is defaults. For my taste, as I am not a UNIX pro, I shy away from using this command in most instances. I find it easier to read and edit .plist files in PLE. However, there is one exception: it is often quicker to add a new property with the defaults command, especially in cases where the .plist file itself does not even exist yet.

In the next article, when we start looking at how to edit .plist files, I will use the defaults command in a few cases where its quickness pays off. For now, if you want to know more about how the command works, you can type man defaults in Terminal.

That's it for this first installment. In the articles still to come, we'll look at how to interpret the content of .plist files, how and why to edit .plist files (including files that you may not have the needed permissions to edit), how and why to access "hidden" .plist file properties, how to troubleshoot .plist files, the function of .plist files that are not stored in Preferences folders, utilities that edit .plist files for you, and more.

Like what you've found in this tutorial? Get more troubleshooting guidance (updated daily) by subscribing to MacFixIt Pro.

  • More from Tutorials

    Join the discussion

    Conversation powered by Livefyre

    Don't Miss
    Hot Products
    Trending on CNET


    Want affordable gadgets for your student?

    Everyday finds that will make students' lives easier: chargers, cables, headphones, and even a bona fide gadget or two!