Property list
| Company type | File format |
|---|---|
| Industry | Software development |
| Founded | 1980s |
| Products | Serialized object data containers for macOS, iOS, NeXTSTEP, GNUstep |
In the development environments of macOS, iOS, NeXTSTEP, and GNUstep, property list files serve as containers for serialized object data. These files, commonly identified by the .plist extension, are frequently employed to handle user preferences and metadata related to applications or bundles, effectively replacing the older Mac OS resource fork system.
For localization purposes during software development, property lists also accommodate string resources through files with .strings or .stringsdict extensions. The .strings files represent a simplified property list consisting of a single dictionary, whereas .stringsdict files are full-fledged property lists. Moreover, Xcode utilizes .pbxproj files to store legacy style plist project configurations.
Data Formats
The abstract data structures defined by property lists can be expressed in multiple encoding formats. The original NeXTSTEP platform used one particular format, while subsequent implementations in GNUstep and macOS frameworks introduced alternative representations.
NeXTSTEP
Within the NeXTSTEP environment, property lists were encoded as human-readable ASCII text files, featuring syntax reminiscent of programming languages; this format was also adopted by OPENSTEP.
- Strings were formatted similarly to C literals; unquoted strings were permissible if they contained only alphanumeric characters and certain symbols.
- Binary data appeared enclosed in angle brackets as:
< [hexadecimal digits] >, with spaces and comments ignored. - Arrays were enclosed in parentheses: , allowing optional trailing commas.
- Dictionaries used curly braces: , with keys represented as strings either quoted or unquoted.
- Comments could be inserted using either or syntax.
- Whitespace was generally insignificant, and statements concluded with semicolons.
This format had limitations such as lacking native support for NSValue types like numbers and Booleans, necessitating their conversion into strings, and it did not define a standard 8-bit character encoding.
The defaults command-line tool, introduced with OPENSTEP in 1996, facilitates manipulation of plist preference files from the terminal, superseding earlier utilities like dread, dwrite, and dremove.
GNUstep
GNUstep extends the NeXTSTEP format by incorporating support for NSValue and NSDate objects using a specialized notation: , where T indicates the type code. For instance, Boolean YES is encoded as , while NSDate instances use a format like <*DYYYY-MM-DD HH:MM:SS +ZZZZ>. Binary content can be efficiently represented in base64 within , and UTF-8 encoding manages 8-bit data.
Additionally, GNUstep offers a binary plist format named , implemented through , which employs single-byte type identifiers and supports string interning via an option.
Two separate plist parsers are present: within (CoreFoundation) and inside (Foundation Kit). Both provide partial compatibility with macOS’s binary and XML plist formats; however, delivers more comprehensive support including GNUstep-specific variations.
GNUstep also includes command-line utilities based on , such as versions of and .
macOS
While macOS maintains backward compatibility with the NeXTSTEP ASCII plist format, it primarily utilizes two proprietary formats: an XML-based plist and a binary plist format. Additionally, it supports a JSON-like format () with limited compatibility.
Evolution
With the release of Mac OS X 10.0, Apple deprecated the original NeXTSTEP ASCII plist format in favor of an XML property list that featured a public Document Type Definition (DTD). This new XML plist supported non-ASCII characters and NSValue objects—capabilities absent from Apple's earlier ASCII-based plist.
To enhance storage efficiency, Apple introduced a binary property list format in Mac OS X 10.2, which became the default format for preference files starting with Mac OS X 10.4. Later on, JSON reading and writing capabilities were added in Mac OS X 10.7, although JSON differs from property lists in that plists natively handle date and data types but do not support explicit null values permitted in JSON.
Tooling
The original tool from NeXTSTEP is still accessible. The plutil command provides an interactive and scriptable editor for plist files.
Introduced in Mac OS X v10.2, the plutil utility validates plist syntax and converts between various formats, including Objective-C and Swift object literals. Similar to Cocoa's NSPropertyListSerialization, it can process "old-style" plist inputs but does not produce them as output.
Starting with Mac OS X v10.5, the defaults tool was added to generate "old-style" plists from any given input. It leverages the -propertyList attribute of Foundation objects to create valid legacy plists, although certain Foundation types, such as Obj-C's NSDate, exhibit specific behaviors. Apple's open-source Core Foundation C code offers a parser named CFPropertyList that supports old-style, XML, and binary plist formats. However, most system tools depend on the proprietary NSPropertyList parser within the Objective-C Foundation framework. While a Swift-based reimplementation exists as open source, it may not behave identically.
Format
Plists formatted in XML and JSON can be modified using any plain text editor. Apple enables plist editing within Xcode through a hierarchical viewer and editor that supports both binary and XML formats but excludes JSON. Since Mac OS X v10.4, AppleScript interfaces have allowed plist reading, with editing capabilities added in v10.5 via System Events.
In XML plists, Foundation classes correspond to CoreFoundation types and their respective XML tags, each with a defined storage format:
| Foundation class | CoreFoundation type | XML Tag | Storage format |
|---|---|---|---|
| NSString | CFString | <string> | UTF-8 encoded text |
| NSNumber | CFNumber | <real>, <integer> | Decimal string; real numbers may include exponents, Infinity (inf), or NaN (nan) |
| NSNumber | CFBoolean | <true/>, <false/> | Tag-only representation (no content) |
| NSDate | CFDate | <date> | String formatted according to ISO 8601 |
| NSData | CFData | <data> | Data encoded in Base64 |
| NSArray | CFArray | <array> | Zero or more child elements |
| NSDictionary | CFDictionary | <dict> | Alternating <key> and plist elements; can be empty |
The binary plist format is described within Apple's open-source Core Foundation C code (). It begins with the magic string bplist, followed by two bytes specifying the version.
Binary plists support data types that cannot be represented in XML or JSON, such as pointers (objref and keyref) that reference an object table. This enables shared references inside arrays and dictionaries without duplication—something XML cannot represent natively. Additionally, the binary format includes a UID type utilized by serialization frameworks like NSKeyedArchiver.
Objects stored in binary plists encompass nil, booleans, URLs, UUIDs, numbers (both integer and real), dates, raw data blobs, strings (ASCII, Unicode, UTF-8), arrays, sets, ordered sets, dictionaries, and UID references. Each object is identified by marker bytes indicating its type and size. Certain types are version-specific (marked as v"1?"+) and are uncommon outside NSKeyedArchiver archives.
After the object table comes an offset table and a trailer that specifies their size and location—both critical for efficient parsing of the binary plist structure.
Serializing to plist
Property lists alone cannot represent every data type necessary for describing arbitrary objects, so an additional encoding mechanism is applied. According to the OpenStep specification, any object conforming to the protocol can be serialized through a subclass of . Two primary archivers are used to convert objects into plist formats:
- transforms objects into binary data chunks resembling tagged structures. Originating from OpenStep, it enables direct serialization to files or embedding within plists, but it mandates consistent read and write sequences. Its usage has been deprecated following the introduction of .
- , which debuted in Mac OS X 10.2, serializes objects into an structure accessed via string keys instead of a fixed sequence. This method maintains an object table array () and references class metadata through UID pointers, with a key marking the root encoded object.
Employing an archiver allows encoding of new data types without modifying the underlying plist format and is Apple's recommended approach for complex types such as NSSets and null values. However, this additional encoding layer increases parsing complexity. Similar to the binary plist format, supports circular references; since XML lacks a native UID type, integers are stored under the key "CF$UID".
Apple distributes an open-source implementation within Swift Corelibs Foundation that limits output to binary and XML formats and includes serialization test suites. GNUstep provides a compatible version without restrictions on output formats.
Path language
Unlike XML’s standardized XPath query language, property lists do not have an official path syntax, though informal conventions exist:
- Apple's plutil utility employs a dot notation in its keypath parameter, inspired by .
- utilizes a colon-based syntax for indexing elements.
Neither convention supports keys containing the separator character used in their respective syntaxes.
Windows
Although primarily linked with Apple environments, plist files also appear on Windows when Apple applications such as iTunes or Safari are installed. On Windows platforms, plist files are usually in binary form, although some applications generate XML or JSON variants.
These files are typically located under and serve mainly as preference storage instead of relying on the Windows registry. Editing capabilities are limited; however, XML or JSON plists can be modified using text editors like Notepad++. Apple supplies plutil.exe within the "Apple Application Support" package (bundled with iTunes), which functions identically to its macOS counterpart.
NetBSD
Introduced in 2006 and released alongside NetBSD#4.0 (2007), the proplib library facilitates data serialization between kernel space and userland, supporting a subset of the XML plist specification.
This library is employed by NetBSD’s second-generation sysmon envsys framework for system monitoring purposes. The proplib library was ported to DragonFly BSD in 2010 and has been included since DragonFly BSD#2.8.
Cross-platform
- Facebook’s open-source reimplementation of the Xcode build system, xcbuild, contains a plist library along with utilities like and , all developed in C++.
- The Python programming language includes a native module capable of reading and writing plist files in both Apple XML and binary formats (available since Python 3.4). ProperTree is a cross-platform editor built upon this module.
- The external ccl-bplist library extends capabilities by supporting NSKeyedArchiver UIDs.
- The Go language offers a package that supports OpenStep text, GNUStep text, Apple XML, and Apple Binary formats, including UID handling in both XML and binary forms.
- For Dart, a third-party library named propertylistserialization provides support for NSKeyedArchiver UIDs as well.