Brent Simmons, who has written more Cocoa apps than you have, sold them to both more users and more companies than you have and spent more time implementing sync for them than all of their other features combined, just posted that he’s dropping Core Data for the syncing version of Vesper (no relation).
Core Data is a distant spritual successor of the long-gone NeXT-era EOF (Enterprise Objects Framework) project. While EOF dealt in object-relation mapping, Core Data is an object persistence layer and works with a variety of persistence stores, atomic or incremental, most of which are either SQLite or fools’ errands.
Quoth Brent, [original emphasis]
So now I’m not using Core Data with Vesper. I hope the people who (quite rightly) like Core Data are not disappointed. I like Core Data too and recommend it.
Consider the below not as criticism of Core Data but as a description of what I personally like. Also consider all the things I’m giving up: faulting, NSFetchedResultsController, the Core Data modeler (I’m using a plist instead), and plenty more.
Brent is clearly happy with Core Data. But he’s also clearly not using it, after wrangling with it for a while. I’ve beta tested several versions of NetNewsWire over the years when Brent developed it and I’ve been hearing Brent thinking out loud on this subject on the beta discussion list for many previous rounds. It’s not the first time Core Data’s been considered heavily, including development, and dropped. (It did make it into some NetNewsWire versions, including NetNewsWire Lite 4.0.) But Brent has detailed his propensity to create things which have the “mark all as read” problem, which is a tall order for an object database: having to materialize the object out of the store just to flip a flag and save all of it back.
So maybe Brent is just a walking pathological scenario. Let’s try someone with even more experience: Delicious Library author Wil Shipley, who’s been writing Cocoa since NeXTStep 0.8x in the 1980s and who knew Craig Federighi when he was on the EOF team. Even Wil’s been fighting Core Data. Not the hard parts. The easy parts. The ones where you get stuff for free and it’s supposed to just work.
Which reminds me: Core Data is also a supported engine for iCloud syncing. It’s supposed to be no more complex than just using Core Data on its own, so imagine everyone’s surprise when it was just as complex as using Core Data on its own. Uncountable apps made the tentative move to iCloud Core Data, and most receded painfully after endless complaints. Apple supposedly made amends and encouraged everyone to “try again”. I’m not sure if that silence you’re hearing is the sound of everything working fine or the sound of no one jumping at the chance to go through that again.
Of Apple’s fixes’ own admission, Core Data sync didn’t work because it was a black box with no ability to debug it. It would be unfair to zing Core Data at large with that epithet. But if it’s something that seems true about Apple’s frameworks, love them mostly as I do, it’s that they’re constructed as if to impress on their user how privileged they should feel because of the difficulty of the bar that they set to solve the problem at, and the complexity of implementation they have used to convincingly solve the problem.
Or to put it another way: Cocoa is so very prone to have heroic solutions that require you unerringly to write heroic or at least merely mistake-less code.
Key-Value Observing. Cocoa Bindings. Retain/release. The thing they invented – ARC – to solve retain/release. Weak referencing
self in blocks or creating memory leaks. Auto layout. I consider myself a decent programmer, but I try to work out the complexity involved in completely implementing all-frills
NSDocument loading and saving and I get winded. There are operating system kernels with lower cyclomatic complexity.
It’s true; other platforms do suffer from not having quite a few elegant solutions present in Cocoa. (Oh, to have every object solve key-based archiving/coding abstractly, so that you can get universal coverage with your own serialization engine;
NSCoding is the most underappreciated piece of design in all of Cocoa.) And it is very neat when it all works. But what about when it doesn’t? What is the cost of demanding if not eternal vigilance, then at least that a fair chunk of your cycles go toward keeping your code at the level demanded by your harsh mistress?
All platforms demand the ability to walk and chew bubblegum at the same time, because nothing’s ever free and most things that are worthwhile won’t be trivial. The role of Cocoa shouldn’t be to appeal to the lowest common denominator. But it has a steeper learning curve than almost any other platform other than idiomatic C++.
There’s nothing inherent about Objective-C that makes complexity come to the fore. The community doesn’t have any problems creating simple frameworks that solve problems. Indeed, it’s interesting how the most popular code seems to be conveniences that sidestep problems in the frameworks as well as alternative frameworks that do less than the Apple-provided frameworks. Less.
I get it. Apple, and NeXT previously, rolls. The baton is passed on, forever, in the name of not reinventing something.
It’s always easy to demand a revolution (and with all this civil unrest, ’tis the season). It’s doubly easy for the guy who thought Apple were working on a new language to want some variant of that to come to fruition after an increasingly embarrassing number of years.
And yes, it’s way too easy to blame the frameworks and the platforms, and to conclude in the reverse that the existence of alternatives does not cast shadows on the things that they are alternatives to.
To all this: OK, sure. But what about the pain? Basic features are still painful for people that have been successful Cocoa coders for ten years. They’re not sufficiently saved by the ripening of frameworks as much as by their own accumulated ingenuity. Cocoa is still being developed, features are added, but rarely does something hard get easier.
Two codas: Brent’s commentary and objc.io issue 10, which is all about syncing and Core Data, rife with stories from the field.