Should You Use Core Data?
When we actually measured the performance of applications adopting CoreData at Apple we invariably got a significant performance regression. Then a lot of effort would be expended by all the teams involved in order to fix the regression, optimization effort that hadn’t been expended on the original application, usually making up some of the shortfall.
[…]
CoreData may well be the best implementation of an in-process-ORM simulating a client-server enterprise app there is, and there is good evidence that this is in fact true (certainly the people on it are top notch and some of the code is amazing). However, all that doesn’t help if that’s not what you need.
This is in response to Drew Crawford’s year-old post, which we’ve been discussing on Twitter. The post stated:
Well, I don’t think there is a real reason not to use Core Data for virtually any project of any size.
It hasn’t aged well given the realities of Core Data syncing.
My view is that Core Data is often the wrong choice but that, unless you know that you will only have a small amount of data, it makes sense as a default choice. Core Data is a generalized framework that’s relatively easy to use. I think it’s often good enough, though some smart people disagree.
For a specific problem domain, you can probably make a custom solution that’s much faster, but that effort may be better spent on other parts of the product. You do, however, need to watch out for what Crawford charitably calls “corner cases,” where Core Data’s performance is abysmal compared to SQLite’s (also a generalized tool). There are probably good reasons that Apple doesn’t use Core Data for applications like Mail and Aperture that deal with lots of data. (It’s interesting to take a look at the SQL that Mail uses.)
A trend I see, among both Apple and third-party applications, is using Core Data (or SQLite more generally) as a cache or cache-like layer. The “real” data is persisted in a more open format. The database is there to manage the working set and provide fast queries.
I currently use Core Data in two of my apps (and am adding it to a third) and have few complaints. However, I don’t always use Core Data objects as my model objects. Core Data’s threading model is unsuitable for EagleFiler, so it uses a sort of repository pattern with plain objects atop the database layer, which can be swapped out. And in some areas it doesn’t use Core Data at all. I see Core Data as a persistence tool, like FMDB, rather than as a complete solution.
Looking forward, Tony Arnold discusses where we are:
The problem is, everyone uses Core Data because there’s nothing better. It’s the best way to persist structured data on iOS and OS X, but it’s not actually much fun to implement and has many warts.
and what he thinks should be improved. To his list, I would add that indexed full text searching is sorely needed.
1 Comment RSS · Twitter
[...] feature, and the underlying SQLite format is robust and open. On paper, Core Data is what an app should use in this case. Yet the iWork team apparently had so little confidence in Core Data (or perhaps the [...]
