Evaluating iOS data storage options: Core Data, FMDB and Realm

To facilitate offline note accessibility, the app will store a large amount of data on the device, so a decent persistence framework is critical.

We didn’t want to assume that Apple’s Core Data framework was the best option, so we evaluated two other prominent libraries – FMDB and Realm.

FMDB

FMDB has been around for a while, and is popular with developers who want maximum performance⁽¹⁾ or who want little to no abstraction. FMDB’s minimal approach is akin to the way we approach interaction with MongoDB in our browser application, so initially this struck a chord with us. However once we’d considered the approach our implementation would take, using object relationship management and model/UI binding, we determined FMDB didn’t offer as much aid as our other options. This would translate into us having to write more code, and as we’re aiming for as early a release as possible that wasn’t ideal.

Realm

I was really intrigued by the prospect of using Realm. Like the rest of the team I have experience with Core Data and plain SQLite, but I have not yet had the chance to put the newcomer through its paces. Unlike our other options it has a proprietary storage engine written in C++ which is purportedly quicker than SQLite, and it does offer the features (relationship modelling, migrations, notifications etc.) we’re keen to employ. From a technical perspective it convinced, but ultimately we chose not to use Realm for three reasons:

• It’s still in beta, and we were unsure if this meant significant API changes in the near future – something we could do without.
• It doesn’t allow concurrent processes to access its files, which according to their documentation at the time this post was written “has implications for iOS 8 extensions”; extensions are very much in our minds.
• We have no experience with it. That’s not something that would always concern us, but given our short timescales and the number of components (including a WYSIWYG and a sync’ing web service) we know we have to hand-roll because there’s nothing open source we can reuse, it’s prudent to reduce risk as much possible.

Core Data

So eventually we decided that while Core Data was the obvious choice, it’s also the most sensible: it’s the one we have the most experience with, and there are plenty of books and articles we can reference should we run into any problems. While there are gaps we’ll need to fill in ourselves, Core Data does have some useful classes, such as NSFetchedResultsController: this integrates with UIKit components to allow us to update the UI as data changes, something we’ll be doing a lot of, I imagine. Plenty of apps leverage Core Data successfully, and with a sound implementation ours will soon be joining them.

1. Which isn’t to say that Core Data is necessarily slow; rather that its features will inevitably introduce a performance penalty, and misuse of it will result in the same. New features like batch updating, introduced in iOS 8, will address some past concerns of iOS developers.