Developer PLISTs FAQ
We build Plistinator for developers who want to use PLIST data in their apps. This page is for you, if you’re still trying to decide if PLISTs are a good way to handle your game or app data, especially in a cross-platform app.
Plistinator is made for editing Plist files! If you already know exactly what you need then Plistinator is ready to crunch your Plists for you. Plistinator is:
- Made for the job
- Simple to Use
- Crunches binary & XML plist files
- On Mac, Windows & Linux
- Continuously Improved
We think Plist is a good format for structured data for apps on all platforms: better at least than the alternatives. And when you have Plistinator it becomes a great format. Need convincing? Read on!
Plist is short for Property List: its a file format for storing structured data. Plists are Open Source and have been around for about as long as the Internet. Plists are known for their use by Apple in gadgets like the iPhone and on the Mac, and it turns out they work great on other platforms too. See below for the dirty details of Plist storage formats.
Plists are ideal for shipping data with your apps, especially if that data doesn’t change much. If the data in your app is structured – for example heierarchical – then Plist can be a better choice for data persistence than a database.
Plists should not be confused with the Java XML Property List file – which can’t store the deep structure that a plist can. Java property lists also don’t have a binary option for efficient storage of large sets of data.
Stable. It’s been around for ages. The birthplace of the Plist file was NeXT Computer in the late 80’s, where it had a text-based format. The modern plists of today, were developed by Apple for its first Mac OSX operating system and have been around since 2000 or so, about the time JSON came on the scene. Plists are in many Open Source projects, including GnuSTEP and Darwin, and Apple’s own OpenSource projects.
Efficient Plists are fast to read and write, and quick to set up: usually its just a one-liner. The XML format is human-readable (more or less) and the binary format is very space efficient, and quick to load.
Structured Plists can do Arrays of dicts of booleans, numbers, dicts, and arrays of… well, you get the idea. Since dicts can map to your objects Plists are a great way to initialise objects in your app.
Open Since Plist is an Open Source format plists are available for all platforms as long as we want to use them. Check plistinator.com’s code resource page for community plist implementations in C++, C#, Java, Python and other languages.
Aren’t plists just XML? Why not cut out the middle-man and just write my data in XML?
Structured data here means
- Typed data (Integers, Dates)
XML is just a serialization format. You still need to implement the structure on top of it. Furthermore if your tools can enforce correctly framed XML, that does not mean they can enforce the structured data semantics on top of it.Structured data formats are only as powerful as the tools you have to edit them: especially when you’re creating quite a bit of data like in a larger game or app.
Plists are not (just) XML. If you try to use a conventional XML editor to create a Plist file, its likely a plist reader won’t be able to read it. Even if the schema is somehow right there must be balanced keys and fields.
This all becomes obvious if more than one person is working on the project. Unless your tools can create actual structured data (like a plist file) then your contributors are going to submit files that are invalid, even though they might be OK as XML. To address this you must write a ton of XML parsing code and validation routines.
Or you can just read a Plist into your objects with a couple of lines of code.
Another reason to choose Plist over raw XML is space and performance – plist binary is small and fast. While you can compress XML that just makes it flakey and slow to load compared to binary plists.
JSON is great, especially for serialising data over the web. It works quite well for storing data in files as well, and there are plenty of JSON serialising libraries around to read and write it. If you are very familiar with JSON and have used it for config files then its probably a good choice for shipping data with your app.
There are two things that we think make Plist a winner over JSON for data-driven apps: first is that Plist has a binary format that is small and fast; second is Plistinator makes sure that the data files you edit are validly framed.
Most tools that can edit JSON allow you to put anything in the tags and labels, so you can create something that is not valid as a data file to your app. Syntax highlighting and indenting can help avoid JSON coding errors but its still easy to make corrupt JSON files – with non-matching braces and so on. This type of framing error especially easy for less technical members of your team who might be say editing levels in your game or working with assets.
With Plistinator you can still spell a tag wrongly or enter incorrect data; but at least its guaranteed to be a valid Plist file. Your code can load it and show an application level error instead of an obscure JSON parse error.
If you’re a JSON veteran and ready to handle the dreaded JSON parse exception in your code, then it’s over to you. But plists are a good choice, and Plistinator is here to make them a friendly and powerful choice.
For Plistinator we handle Plist with the following types:
- Boolean (either true or false)
- Number (can be real or integer)
- String (utf-8)
There are some interesting differences between the binary and XML format
- Binary has a UID data type which is used on Mac for serializing certain binary data types mainly in preference files.
- Binary also has an explicit null type. Rarely seen in the wild.
- Binary can do a ASCII string type, as well as the UTF-8 string. In practice this becomes just another way that binary can store data in a more compact way.
UID: Plistinator can read these and represents it by creating a single element Dictionary with the UID as a number child element. When creating structured data for an app this curiosity can be ignored. There is never a reason to want to create a UID: but Plistinator supports it in this way so you can read Apple Mac binary files if you want to.
ASCII: When serialising to binary, Plistinator examines strings and if they can be stored as ASCII when binary is requested this is done, to save on space and make for faster loads.