I agree in general. But XML as used in plists is actually not especially complicated, if you aren't trying to be a webbrowser and tolerate invalid input.

Your security-sensitive parser should not attempt to tolerate invalid input.

Probably you should not have multiple separate implementations of it, either.

I’m not sure that there were much better choices available at the time. IIRC property lists date back to NextStep.

By the time stuff like JSON started popping up, plists were pervasive all throughout OS X. Typical legacy problem!

Property lists in NeXTSTEP didn't use XML but rather a different text-based format.

https://developer.apple.com/library/archive/documentation/Co...

Plists support dates (json doesn’t explicitly), and has you explicitly type the contents, which can help make sure that when you want a string you don’t get an int.

I wouldn’t view it as a legacy problem. There’s no actual need to change to another format (JSON etc?) just for the sake of it.

Property lists have a JSON format, interestingly.

The format plists used before XML was very JSON-like. It had its own set of issues, however.

They could always drop XML for YAML and get more issues!

I dislike XML and would not chose it for my projects. But... in this case, it does seem like a good idea to require explicitly closed tags. Seems like it could remove 1000 error potentials for every 1 parser error.

Yeah, an XML parser that allows invalid XML (tags must be closed, per the spec[1]) is pretty clearly a terrible choice for a security-sensitive purpose. Likely it was just oversight / accidental reuse, and it's a somewhat common error, but it's very much an engineering mistake and not an XML flaw.

[1] It's very clearly stated as item 2, in a 2-item list for well-formed-ness of documents: https://www.w3.org/TR/xml/#sec-well-formed

http://langsec.org/ !

Problem is legacy software tends to use XML. iOS can be considered legacy at this point. Plists are prevalent at every level of iOS.

As somebody who was already a high school student deeply ‘into’ computer technology at the time, I perfectly remember the hype and release of XML.

IOS was released last week by mental accounting standards.

To hear both be branded as ‘legacy’ is, frankly... well, it makes me feel ancient.

You shouldn't feel too ancient, as the label is grossly misused by GP in characterizing iOS and XML :-).

XML came out in 1998, iOS in 2007 (or a year later for the SDK). It’s closer to XML than to today.

So much has been rewritten you can’t really call it legacy at this point.

Fair enough. When I worked for Apple, I would often take a gander at the iOS source code. There was a lot of legacy stuff in there, as in, "do not modify this method, we don't know what it does" in comments. There were certainly legacy components in there from many years back, and it didn't seem like tech debt was on the radar. At least when I was there.

Certainly there are various bits that are legacy and behave like that, but generally speaking, calling the entire thing legacy is a bit of a stretch. Also considering it started in 2007, I think the definition of legacy is quite short termed here. It also implies a negativity, that if you’re not jumping from technology to technology then you’re doing something wrong. I disagree with that viewpoint.

As someone currently taking a break from reverse engineering the internals of CoreGraphicsServices on macOS, I can't resist saying that iOS can't possibly be as legacy as this.