Breaking News: Realm is Deprecated. What now? Also, Told You So!
Several days ago, on September 9th 2024, MongoDB announced the deprecation of Atlas Device Sync + Realm SDKs in September 2024. What does that mean for current users? Where do we go from here?
Several days ago, on September 9th 2024, MongoDB announced the deprecation of Atlas Device Sync + Realm SDKs.
NOTE for those who are not familiar with Realm. It is a database and ORM solution for mobile applications that has, besides database functionality, various other features for data syncing with the backend.
The update was announced via email and an update in the README of Realm iOS repo:
TLDR - users of Realm with Device Sync (cloud data syncing solution) will have to migrate another implementation (3rd party or their own) by September 30, 2025.
The client side Realm database implementation (and the syncing features on the client side) will continue to exist as an open source project. Without MongoDB dev support I would imagine.
What does that mean to you, a mobile engineer?
Of course, if you have never used Realm for your database or backend data syncing solution, you have nothing to worry about.
But, if you were an existing user of the database solution, and ESPECIALLY if you built on top of their Device Sync solution, then you have trouble at your door.
What you might want to consider is to migrate away from Realm to some other database solution.
Solutions and things to consider
If you are already using Realm in your projects today then there are two possible scenarios for your implementation of it:
you use it as a DB storage layer
you use it a pseudo networking data sync layer.
Realm as database storage layer
My hope is that you have a well structured codebase where your data storage layer is completely decoupled from your database/ORM solution and you can replace Realm with Core Data or something else with ease.
The main concern for you would be data migration which you could do gradually over time, starting from one entity/table/domain model at a time, to reduce risk.
Of course, there is a chance that you don’t have a clear-cut decoupled storage layer and the usage of Realm is spread out across multiple layers and corners of your codebase (maybe even in the UI?). In that case, the first thing you’d need to do is to refactor your code so that any Realm database related code is encapsulated and wrapped around in your own custom object implementations and clear interfaces for interaction with them are established. After that, you can proceed with replacing Realm usage with something else like Core Data in that encapsulated layer and its objects.
This would follow the good old Martin Fowlers (or Kent Beck’s? I forget) adage - “make the change easy and then make the easy change”.
Realm as a networking data syncing layer
It already is not a trivial task by itself to replace your storage database layer but it will be even more complex if you also used Realm as your pseudo networking data syncing solution.
You really only have two options:
decouple your codebase from Realm usage into a storage layer encapsulation, start implementing networking layer for the new custom backend syncing (aka sending the data back and forth the normal way via POST/GET/something else)
implement Device Sync replacement in your own backend to keep the client side mobile implementation intact
Decouple Storage from Realm and start implementing Networking Layer
Just like with any refactoring or dependencies change, your approach should start with laying the ground work to make the change easy and then implementing the refactor or dependency swap.
Start encapsulating your Realm calls in a Repository object or similar and then gradually decouple the logic into local storage specific and networking/data sync specific implementations.
Eventually, you’ll be able to start replacing your networking calls to Realm with your own backend implementation.
Implement Device Sync replacement on the backend
As an alternative, you can always go for reimplementing what Realm does on the backend for you in your own server. I am not familiar with the actual underlying tech there (is it HTTP GET/POST or sockets or something else?) but in general you’d have to consult Mongo docs on the topic to roll out your own.
Magical Backend Replacements Never Work! Told you so!
Another too-good-to-be-true solution falls victim to its own hubris. First it was RESTKit, then Parse, and now Realm.
All of them promised seamless local database and backend data syncing solutions. But all of them were ultimately terrible pieces of technology to use. They broke Single Responsibility Principle by doing too much (are you a database or a networking layer?? why do you do both?) and they “forced” users to couple their codebase to their solutions too much.
Some of these solutions, like Parse, even promised to replace your backend entirely, what a claim!
I was against those solutions as they came out way back in the day. No automation can ever replace custom bespoke backend logic necessary to build any useful application. I only wish I had an article or some other record artifact to refer back on my thinking back then.
I wanted to write this article in the hope that it would prevent at least one mobile engineer from falling victim to the allure of such poorly thought-through technologies. This is why I’m adding Realm mentions (and of pitfalls of such solutions) to the 2nd edition my book The iOS Interview Guide. Subscribe to stay tuned on the book’s update process.