7 ms·

plists absolutely cannot contain arbitrary Objective-C objects. They support a subset of Foundation container and value types and are not extensible to contain

plists absolutely cannot contain arbitrary Objective-C objects. They support a subset of Foundation container and value types and are not extensible to contain other types.

fiddlerwoaroof 5y ago
Any Codable can be written to or read from plists, right? Anyways, it’s definitely true that plists support a superset of the data types supported by JSON: plutil will not convert the Safari bookmarks file to JSON, for example.
- saagarjha 5y ago
  No, property lists have a limited number of types that they support: https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/PropertyList.html https://developer.apple.com/library/archive/documentation/Ge...
  - fiddlerwoaroof 5y ago
    As far as I know, any Codable can be roundtripped through plists: https://www.donnywals.com/reading-and-writing-property-list-files-in-swift/ https://www.donnywals.com/reading-and-writing-property-list-...
    - lstamour 5y ago
      So the answer is yes, both are true. On the one hand, a plist can only contain strings, floats etc. On the other hand, an app can use plist files to store whatever it likes, just as a text file doesn’t limit you to plain text if you want to use Base64, for example. So while it is true that you can use these tools to convert a Plist from a binary or legacy format to JSON or XML and back, there are no guarantees you’ll be able to understand what was written to the plist originally. The plist format does not encode metadata describing itself in any common standardized way: it’s not a JSONSchema, an XML Schema or even a protobuf .proto file. A well-written plist can be as self-describing as JSON or XML, though the concept of a schema for plist files doesn’t exist as far as I’m aware, outside of how apps choose to serialize objects, that is. (The data structures an app uses could be considered a schema for a plist but it assumes the data structures themselves are versioned when they need breaking changes…) https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html https://developer.apple.com/library/archive/documentation/Ge... has an example of “stringly-typed” keys and values. There’s not much validation in a generic plist editor just as there isn’t validation in JSON or XML by default, but any app can add its own validation to ensure what it saves to a plist is something it can read later… that’s where the confusion over objects and codables comes in. If an app wrote the object to a part of a plist, it can thus de-serialize it from how it wrote it. If your app doesn’t understand another app’s plist, that’s pretty normal for complicated files or data kept by third-party apps. Few apps consider metadata and longevity when they write to disk, such that migrations are handled version to version as they need to, etc.

plists absolutely cannot contain arbitrary Objective-C objects. They support a subset of Foundation container and value types and are not extensible to contain other types.

fiddlerwoaroof 5y ago

Any Codable can be written to or read from plists, right? Anyways, it’s definitely true that plists support a superset of the data types supported by JSON: plutil will not convert the Safari bookmarks file to JSON, for example.

saagarjha 5y ago
No, property lists have a limited number of types that they support: https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/PropertyList.html https://developer.apple.com/library/archive/documentation/Ge...
- fiddlerwoaroof 5y ago
  As far as I know, any Codable can be roundtripped through plists: https://www.donnywals.com/reading-and-writing-property-list-files-in-swift/ https://www.donnywals.com/reading-and-writing-property-list-...
  - lstamour 5y ago
    So the answer is yes, both are true. On the one hand, a plist can only contain strings, floats etc. On the other hand, an app can use plist files to store whatever it likes, just as a text file doesn’t limit you to plain text if you want to use Base64, for example. So while it is true that you can use these tools to convert a Plist from a binary or legacy format to JSON or XML and back, there are no guarantees you’ll be able to understand what was written to the plist originally. The plist format does not encode metadata describing itself in any common standardized way: it’s not a JSONSchema, an XML Schema or even a protobuf .proto file. A well-written plist can be as self-describing as JSON or XML, though the concept of a schema for plist files doesn’t exist as far as I’m aware, outside of how apps choose to serialize objects, that is. (The data structures an app uses could be considered a schema for a plist but it assumes the data structures themselves are versioned when they need breaking changes…) https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html https://developer.apple.com/library/archive/documentation/Ge... has an example of “stringly-typed” keys and values. There’s not much validation in a generic plist editor just as there isn’t validation in JSON or XML by default, but any app can add its own validation to ensure what it saves to a plist is something it can read later… that’s where the confusion over objects and codables comes in. If an app wrote the object to a part of a plist, it can thus de-serialize it from how it wrote it. If your app doesn’t understand another app’s plist, that’s pretty normal for complicated files or data kept by third-party apps. Few apps consider metadata and longevity when they write to disk, such that migrations are handled version to version as they need to, etc.