Marco Arment’s Core Data alternative that sits on top of SQLite and FMDB is on GitHub and looks excellent. Core Data has generally worked well enough for me, but maybe not so well that I’m not interested in alternatives. What he’s done is make something simple with a couple of great features built-in:
- Multi-threading support: Database operations happen concurrently via a serial queue, so you shouldn’t stomp all over yourself. I assume if you’re accessing your model objects in your own threads the normal rules apply.
- Active record style access: You only need to worry about talking to your model objects and classes, which is simpler in most cases than the way Core Data does it.
- Simple schema migration: You can version your database and then receive a callback to update your schema as needed.
The whole thing is pretty similar to what Brent Simmons describes in his objc.io article about using SQLite instead of Core Data. Brent raises a couple of reasons for wanting to do something a bit different in his article. Mostly it comes down to hitting performance walls and wanting something that’s just a bit simpler and less general. The truth is that because Core Data is a general solution which completely abstracts you away from the idea of using a database, I’m not sure there’s anyway that it couldn’t be a bit complex in places and that there wouldn’t be walls to bump up against. In my experience with Core Data everything works great except when it doesn’t, and because you’re so abstracted away from the implementation detail of it using a SQLite store, when you do hit those walls, you hit them hard. Some things I’ve run up against with Core Data are:
- Threading still sucks, even if it has gotten better.
- Tries to solve for edge cases I'm not sure anyone has and is overly complex because of it.
- Having to pass around an
NSManagedObjectContextto do just about anything. - When you have problems, it's not always easy to find documentation that explains what's going on.
All of that being said, I still think that Core Data does do a lot for you. The first three issues I raise are mostly mitigated by having good code hygiene and also by using MagicalRecord. Taking the time to read the documentation and also Marcus Zarra’s book on the topic (before you start using MagicalRecord), would probably solve a lot of problems for people as well.
As far as performance goes, it wasn’t easy to get there, but Pinbook imports bookmark collections in the range of 20,000+ in a few seconds on an iPhone 4S, so it is possible to get very high performance when using Core Data. I can’t imagine there’s too many iOS apps out there that have those kinds of performance requirements.
There’s also some specific things that Core Data really makes a lot easier. For example, it’s batching and faulting mechanisms work really well. One thing that I did not have to think about very much when developing an app that might need to display 50,000 items in a table view was managing memory for those items. I’m sure I could have come up with a way to handle that using a custom solution, and it wouldn’t have even been that hard, but with Core Data it was practically free. I’m also hearing from friends that Core Data sync might be finally working the way it should in iOS 7, and if that’s true, and I write an app which really just needs to make sure a users data remains in place between iPhone, iPad and Mac versions, would be awesome, although I’m not holding my breath until I have time to play with it myself.
No general solution will ever be perfect fit for every case. In those cases writing a custom solution is nothing to fear. If you’re writing a Mac or iOS app, however, Core Data probably is the right fit most of the time, and you should really consider what you’re doing when it’s not.
