Xcode’s new Core Data model file format, introduced with Xcode 4.1 in 2011, never made any waves in Cocoa development blogs that I saw.1 Which is a shame, because it’s a pretty kick-ass improvement. Instead of a binary plist format (more specifically, Cocoa objects serialized directly to disk in a binary plist format), it’s eminently readable and diffable XML.
It reminds me, for two reasons, of Mark Pilgrim’s complaint about Apple’s switch from the standard .mbox format to the (Spotlight-friendly, but undocumented) .emlx format in Mail.app in Mac OS X 10.4, which was part of his rationale (last straw?) for leaving the Mac ecosystem and moving to Linux. (See this Daring Fireball article about it, since Pilgrim’s blog posts are now only available via the Wayback Machine.)
For one, it’s because my experience with the new format involved what I remember to be an involuntary switch. The details are a little fuzzy for me now (a good reason to write these blog posts in a more timely manner), but I recall my edits being saved in the new format without my having done anything to warrant it, and without any prompting on Xcode’s part. Just like Mark’s experience in Mail. If Xcode did make a habit of that, I would be rather annoyed, and for the same reason. (As an aside, I go on about this at some length in my first podcast (link forthcoming2 due to this mistaken remembrance. See the second podcast for followup, or just read the rest of this post.) I’m a sophisticated enough user that I care about format switches, mostly for the sake of backwards compatibility. For non-technical users, losing that compatibility might be fine. Developers, however, are by their nature not non-technical users.
It turns out, I can’t reproduce that experience now with fresh reinstalls of Xcode 4.0.2, 4.1, and the latest Xcode 4.3.2. Instead, the only thing that changes the format is for you to explicitly change it in the model’s inspector pane. Which is great. Exposing that level of control over a file’s format is exactly what a developer tool should do. And they do it for other important file types too, like xibs. So, kudos.
For two, it’s because this is kind of Mark’s experience in reverse. Going from a less standard format to a more standard format. (I did say “kind of”.) While it isn’t documented, it is uncluttered, as far as I can tell, by the kind of unreadable binary garbage that pollutes other XML file formats. Entities are referred to solely by name, not UUID. Attribute titles are simple and understandable. From a practical perspective, this will make the SCM diffs you do every day far more useful and enjoyable. But I could also see someone using a script to mechanically put together a Core Data model file, much more easily than you would put together an Xcode project file. And going further, I could see someone writing a third-party Core Data modeling tool that spits out one of these. I’m almost surprised someone hasn’t done it already, though the Xcode 4 Core Data modeling tool is good enough (and free) that there probably isn’t much demand for it.
Weaponized Fluff 