Talk:Property list

Mac OS bias (ignoring NeXT and GNU)

This article, before I got to it, had what I would call a "deep Mac OS bias". That is to say, it ignored NeXTSTEP, which is where plist files originated, and GNUstep, which also implements plists. I've tried to fix that, along with other factual inaccuracies. – Andyluciano 22:43, 23 December 2005 (UTC)

Move?

I think this page should be moved to something like Property List, property list, Property List file, or property list file. – Mipadi 16:52, 6 April 2006 (UTC)

Recent edit

Removed advertisement (which was factually incorrect to boot; said that a GUI tool was a command line tool). Imo, a list of plist editors apart from Apple's own does fit with the article, but in the External Links section or something, not where it was before my edit. --Devnevyn 15:05, 10 April 2007 (UTC)

MIME type?

Is there MIME type for plist? May I suggest application/vnd.apple.plist+xml —Preceding unsigned comment added by 82.70.200.181 (talk) 10:52, 9 June 2009 (UTC)

Nokia

OMG! The Nokia "Web Runtime" widget format uses a plist file! See: and
Of course Nokia defines their "own" DTD, but the file looks just like a Mac OS X plist. Maybe this has to do with the browser being based on Webkit? Nice influence however..  >;-)
--81.10.136.83 (talk) 18:05, 22 March 2010 (UTC)

Dead Applescript feature link....

http://www.apple.com/applescript/features/propertylists.html is improperly used in the article, and the link is dead; it redirects to something generic now. I suppose I could replace it with http://web.archive.org/web/20090424003555/http://www.apple.com/applescript/features/propertylists.html but .... well, I'll do that, and convert to a reference...--Elvey (talk) 00:51, 5 October 2012 (UTC)

Naming Convention

Can someone add a section about the naming convention of plists? It's the information I was looking for on this page and didn't see it. (Specifically, I was trying to figure out why all the plists start with com or org before resolving to the application). — Preceding unsigned comment added by 76.91.29.182 (talk) 22:51, 24 January 2013 (UTC)

The filenames you're referring to are Uniform Type Identifiers, which is a reverse-DNS naming structure used throughout macOS to identify its equivalent of namespaces. Plists don't have any inherent naming structure of their own, and the ones contained within ~/Library/Preferences are named after their respective preference domains (that is, the identifier you pass to the defaults(1) utility: $ defaults read "$DOMAIN" "$PREF_NAME"

Even the .plist file extension isn't set in stone, as macOS uses other extensions (mostly for internal use) that contain plist(5) data, such as .sfl2 (Shared File Lists), .savedSearch (Smart Folders created by Finder), and even .webarchive files created by Safari when saving a complete webpage to disk.
— Alhadis (talk) 14:29, 9 April 2026 (UTC)

Many Issues

1. This page is still biased toward OSX.
2. As such the page talks about property list files, specifically OSX implementation of such files.
3. Property lists are also a type of Associative array, which is a Data type.
4. There is no mention of Lisp which has used plists since its inception , or at least since 1990.

This page should be named "Property List (File)" and another page similar to Hash Table should be created, or This page should keep the name, but become about Property Lists in general (Data Type, File Type, Applications in Systems, Applications in Computer Science or Programming). 173.15.164.249 (talk) 19:00, 10 February 2016 (UTC) Elijah Beale

Yes, I agree, especially with the OSX bias. DoggieTimesTwo (talk) 22:48, 22 May 2020 (UTC)

IMHO, I would consider adding a {{hatnote}} or {{hatnote group}} referencing associative arrays and any relevant subsection within a Lips-related article (such as one that discusses alists). I understand the page is biased towards macOS/GNUstep/NeXTSTEP, but considering that Apple's Property List is a well-established format with widespread currency, I think this page's name should remain as-is.
— Alhadis (talk) 15:18, 9 April 2026 (UTC)

References

Too short of a "See Also"

The See Also section seems too short for a big heading. Maybe merging it to another section or making it smaller? DoggieTimesTwo (talk) 22:48, 22 May 2020 (UTC)

Lacking citations about NSSerializer

The article says "(The Cocoa NSSerializer from before Mac OS X 10.2 emits old-styled output.)", but it does not provide a source, and I have some reason to doubt it is true.

I did some digging – none of it is conclusive evidence in either direction. But perhaps it's interesting, or will help find a more conclusive source:

• NSSerializer and NSDeserializer are still shipped with the Foundation framework under macOS 15 – but they do not seem to produce an old-style plist or any kind of encoded string. Instead, the output seems to be binary-encoded. This can be tested by installing pyobjc and then running from Foundation import *; bytes(NSSerializer.serializePropertyList_({"Hello": "World"})) and inspecting the resulting bytes.
• The OpenStep spec does not specify what output format NSSerializer produces, it just says it produces 'an abstract representation of a property list [...] in an architecture-independent format': https://www.gnustep.org/resources/OpenStepSpec/FoundationKit/Classes/NSSerializer.html
• When encoding to XML using the replacement for NSSerializer - NSPropertyListSerialization – it does seem to produce NSData representing a string. This sounds similar to what the Wikipedia article is claiming. It can be tested using pyobjc with the command from Foundation import *; bytes(NSPropertyListSerialization.dataWithPropertyList_format_options_error_({"Hello": "World"}, NSPropertyListXMLFormat_v1_0, 0, None)[0]).
• The GNUStep docs mention that the output of NSSerializer is NSData that actually represents a string. That sounds very much like what the Wikipedia article talks about, but it seems to only apply to GNUStep not to macOS - perhaps the this is the origin of the misunderstanding? https://www.gnustep.org/resources/documentation/Developer/Base/Reference/NSSerialization.html#class$NSSerializer

92.117.213.226 (talk) 16:32, 22 April 2025 (UTC)

Context: I dug into this because I wanted to find out if there's still a way to create an old-style plist on modern macOS. So far I couldn't find a way, but I think there has to be one, since Xcode's own .pbxproj files are still old-style plists – with comments! – Something that neither JSON nor modern XML plists support. 92.117.213.226 (talk) 17:12, 22 April 2025 (UTC)

You can use the pl(1) utility to convert an XML property list to the "old-style" (OpenStep) format, but there are numerous limitations: the conversion is one-way, badly-indented, and worst of all, lossy (in the sense that certain objects, like <data> and <date> objects, are converted to an approximation of their contents. I wrote a utility named convert-plist(1) that performs lossless, two-way conversion between XML and OpenStep property list formats (with a man page to boot).

Normally, I wouldn't use an article's Talk page to advertise my own work, but in this instance, Apple's own pl(1) utility is borderline useless for meaningful conversion, to a point that recommending it didn't feel like an adequate answer to your question.

Hope this helps!
— Alhadis (talk) 14:11, 9 April 2026 (UTC)