If you’ve done any kind of iOS development lately, you’ve run into a decision we all need to make at some point – how am I going to implement object persistence? For years and years, the only options you had were SQLLite and CoreData. Most people went with CoreData because it had less boilerplate code compared to SQLLite. By comparison it was also easier to setup.
Now there’s a new player in the game, and it offers similar improvements to your iOS development experience. Realm is a mobile database solution that promises even less boilerplate code, easier migrations, and a learning curve that isn’t so steep. Does it live up to its promises? What are the pros and cons of adopting Realm compared to other totally fine data persistence frameworks?
As a developer who is accustomed to favoring Apple’s frameworks over others, it generally feels strange to step out of the walled garden and work with a third party framework for such a generic thing that all apps need. After all, CoreData has been around for a long time. It has been battle tested in millions upon millions of applications. If we’re going to leave the walled garden, there had better be a darn good reason to do so. At the very least, we might want some evidence that the walled garden is in a state of decay and our true paradise lies elsewhere.
To drop CoreData and go with Realm is an exercise in trust. You are trusting that a third party can do a better job than Apple itself. You are buying into the assumption that Apple hasn’t done such a great job of innovating within the realm of object persistence (pun intended). In the long term, you believe said third-party will still exist in a few years time when your app and its database will likely need support and maintenance. Fundamentally, you accept the premise that Apple has failed to keep pace with current trends in mobile database architecture, and a third party can do a better job of carrying that flag forward.
Would you be correct in accepting that premise? Considering the recent decline in the overall quality of Apple’s software, it’s no surprise so many developers are ditching CoreData. Apple has its hands in a lot of different places and their limited development team is under constant pressure to keep rolling out new public-facing features every year. They’ve done all of this while inventing a totally new programming language that paves the way for the next era of programming. If they’ve been a little lax in investigating what they could do to make CoreData better for developers, it would be no shock.
TLDR; Core Data is old. It hasn’t changed that much recently. It’s still based on SQLLite, which was super hot in 2000 but has since been surpassed by faster tools. Compared to Realm, CoreData feels heavy, and for most simple uses CoreData feels like bringing a machine gun to a fist fight.
But how much better is Realm? Is it that much easier to setup? Does it fully escape the constraints imposed by CoreData, or does it follow in CoreData’s footsteps too much? How much faster is it? To what extent can it help us avoid the most time-consuming problems that relate to persistence, things like multi-threading and migration? We should endeavor to investigate each of these questions in detail.
Claim: Realm is easier to setup. It requires less boilerplate code. True or False?
True. Although Apple does go to great lengths to help you avoid writing much of the necessary boilerplate code to setup CoreData, said boilerplate code is still required. You still need the various CoreData related functions in your AppDelegate, which are generally easy to add if you’re starting a project from scratch but a bit harder to add when you want to bring persistence to an existing project. As a developer, this forces you to make some pretty big decisions about persistence right out of the gate, decisions that add weight to starting up a project.
On top of this, you need to support XCDataModel files when you opt to go with CoreData. It’s not exactly boilerplate code, but it’s an extra file you need to modify just to add a single persistence-backed entity. Realm does away with all of this. With Realm, you simply install the cocoapod and subclass RLMObject. There’s no doubt about it. There’s definitely less setup time.
Claim: Realm requires less code overall. True or False?
True, especially when you include the boilerplate code you need to setup NSManagedObject contexts. A side-by-side comparison of a simple fetch request shows that Realm can accomplish in three lines of code what Core Data does in several.
Claim: Realm is easier to work with in multithreaded situations. True or False?
Mostly true, although it should be said that both are kind of a pain when it comes to multithreading. With CoreData, you have to manage a bunch of separate NSManagedObject Contexts for the different threads whereas with Realm, you need separate RLMRealm objects for different threads.
Either way, there’s some extra effort to understand what’s going on, and it often throws most developers. We were working on a project, had decided to go with Realm, and instantly ran into unexpected behavior when we needed to update some objects on a background thread. We sort of expected to be able to use the same RLMRealm object in any thread, and that wasn’t the case.
All told, I will say Realm is better at multi-threading than CoreData. It’s far easier to create another RLMRealm object than to manage multiple NSManagedObject contexts with different data merging policies (which just seem like way more than any sane developer needs to know to persist a few objects). With Realm, you will still be annoyed. Albeit less so.
Claim: Realm is faster than CoreData. True or False?
True. Realm breaks away from SQLLite and employs a number of new techniques behind the scenes to make fetch operations much faster than CoreData. This is the area where Realm makes CoreData look old, and rightly so. CoreData has been in need of an overhaul for a long time, and it still suffers from being tied to early 2000s era technologies.
Claim: Realm breaks from the major design patterns and paradigms tied to CoreData. True or False?
False. For all of the advances that come with the Swift programming language, Realm is still tied to a class heavy architectural paradigm. Just like with CoreData, you do most of the work by subclassing Object, a Realm class (Core data has you subclass NSManagedObject). This isn’t bad. In fact, it could be argued that this is exactly the sort of thing you would want. We generally want our persisted entities to be reference types because that means different parts of the app can point to the same entity. When we make changes to that entity, the changes are updated everywhere in the app as opposed to just one place.
However, for those of you who were hoping for something more lightweight, you aren’t going to find it here. In many ways, Realm follows the same patterns found in CoreData. The difference is in the total amount of code you need to write to implement your version of those patterns.
I have nothing but respect for the Realm team, and not just for the work they’ve done on Realm but also the work they’re doing to engage the greater iOS development community. Lately it seems like the most informative articles on the newer Swift technologies can be found on their website. That gives me more comfort believing they’re in it for the long haul. They’ve been been hard at work bringing together a talented group of people who really understand what Swift is all about.
As a product, Realm is the easy-to-setup persistence solution we’ve been wanting. Nearly all of the things you’re hearing about it are true. Having used it in a recent project, I have nothing but good things to say. Granted, it doesn’t solve all of the headaches that come with CoreData, but it does solve enough of them to make the move worth the while. Although it can feel unsettling to leave behind a battle-tested Apple supported product like CoreData, Realm is the rare exception to the rule. It gets my thumbs up.