Realm schema migration: avoid data loss on mobile app updates

Realm database migration: avoid data loss on update

Realm throws Migration is required due to the following errors when the schema doesn't match. If an app with 10,000 users doesn't set up a proper migration, the update will crash every tenth user — and negative App Store reviews are guaranteed. Unlike Room or Core Data, Realm requires explicit specification of the current schema version in the configuration — and if you forget it, the app will crash on the first database access. Our experience shows that a correctly configured migration from the start eliminates downtime and reduces testing time by 30%.

How Realm determines the need for migration?

The schema version is stored inside the .realm file. Realm compares the version in the file with the version specified in RealmConfiguration.schemaVersion. If the versions don't match and migrationBlock is not set — an exception. Developers often forget to increment schemaVersion — this leads to a crash for 90% of users on update. The cost of such a bug is loss of reputation and time for an emergency release.

// iOS — base configuration with migration
let config = Realm.Configuration(
    schemaVersion: 3,
    migrationBlock: { migration, oldSchemaVersion in
        if oldSchemaVersion < 2 {
            // Migration 1 → 2: added category attribute
            migration.enumerateObjects(ofType: Transaction.className()) { old, new in
                new?["category"] = ""
            }
        }
        if oldSchemaVersion < 3 {
            // Migration 2 → 3: rename field
            migration.renameProperty(onType: Transaction.className(), from: "note", to: "description")
        }
    }
)
Realm.Configuration.defaultConfiguration = config

According to the official Realm documentation, all migrations from any older version to the current one are executed in a single migrationBlock — Realm itself determines which version to start from. If you have 5 versions and the user's file is at version 1, Realm will apply all intermediate steps sequentially.

Why is it important to configure schemaVersion correctly?

Every time you change the data model (add, remove, rename fields), you must increment schemaVersion by at least 1. If you don't, Realm will throw an exception when trying to open the database on the user's device. Imagine: you release an update with a new model version but forget to update the schema version — all users (could be a million) won't be able to launch the app. The cost of such a bug is measured not only in fix time but also in reputational loss. We guarantee this won't happen in your project. Savings on support after a proper migration pay for themselves in 2–4 weeks.

What types of operations are supported in migrationBlock?

Adding a field

Realm automatically adds new fields with default values only if the field is optional or has a default in the model. For filling with non-standard values — enumerateObjects. On Android (Realm Kotlin SDK), migration is configured via AutomaticSchemaMigration:

// Android (Realm Kotlin SDK)
migration.iterate("Transaction") { oldObject, newObject ->
    val oldCategory = oldObject.getNullableValue<String>("category")
    newObject.set("category", oldCategory ?: "uncategorized")
}

Removing a field

Realm simply ignores fields that don't exist in the new model. No explicit migration is required — but you still need to increment schemaVersion. This often causes confusion: developers think removal is safe, but if the version isn't updated, Realm throws an exception.

Renaming a field

migration.renameProperty(onType: "User", from: "fullName", to: "displayName")

This preserves data. If you delete the old field and add a new one, data is lost. We recommend always using renameProperty to maintain backward compatibility.

Changing a field type

Direct type conversion is not supported — this is a Realm limitation. Approach: read the old value, write to a new field of the new type, then remove the old field from the model (Realm will delete it automatically). For example, if price was a string and becomes a floating-point number:

migration.enumerateObjects(ofType: "Product") { old, new in
    let priceString = old?["priceString"] as? String ?? "0"
    new?["price"] = Double(priceString) ?? 0.0
}

How to debug migration with Realm Studio?

Realm Studio allows you to open a .realm file and view data before and after migration. Useful for verifying correctness. File on Android: /data/data/<package>/files/default.realm (accessible via Device Explorer in Android Studio). Realm Studio processes files 50% faster than direct browser viewing and supports filtering by classes.

How we guarantee correct migration: process and testing

Schema migration is a critical operation. An error leads to data loss, and backup recovery is not always possible. Our engineers have 5+ years of experience with Realm and guarantee correct execution of all transitions.

1. Analyze the current schema and change history.
2. Write migrationBlock for all transformations.
3. Test on Realm Studio and on real backup data.
4. Integrate into the project and deploy via App Store/Google Play.

What's included in the work

We provide:

• Documentation of schema changes with a description of each step.
• Migration code with unit tests and integration tests.
• Rollback instructions for the previous version.
• Support during deployment for 2 weeks.

Migration cost is calculated individually, but often the savings on support pay off within a month. Order Realm migration right now and get a data safety guarantee. Contact us — we will evaluate your project within one business day.

Typical Realm migration mistakes (and how to avoid them)

• Forgetting to increment schemaVersion — the app crashes for all users. Always verify that the version is incremented by at least 1.
• Skipping handling of nullable fields — data turns into nil/null. Use enumerateObjects for explicit assignment.
• Renaming a field by deleting and adding — data loss. Always use renameProperty.
• Using different SDKs in the same project (Java + Kotlin) — library conflict. Choose one SDK and stick with it.

Timelines: from 1 day for simple migrations to 3 days for complex multi-step transitions. We'll evaluate your project for free. Get a Realm migration consultation today — contact us and we'll offer the optimal solution.

How to Choose a Local Data Storage Solution (Room, Core Data, Realm, Isar)?

We've all seen the scenario: the app loses data when the network drops — and it's not just a bug, it's a failure of the use case. The user fills out a form, taps "Submit", gets a timeout, and loses everything. Or worse: data gets sent twice due to incorrect retry logic. A properly chosen and configured storage layer solves this problem once and for all. The wrong choice can cost teams months of rewriting code and up to 70% of time spent on synchronization. Our experience — 10+ years in mobile development, over 50 projects with offline storage — confirms: the storage choice determines 80% of future performance and synchronization issues.

In practice, storage selection is driven by two factors: data type and synchronization requirements, not library popularity.

Room (Android) — a wrapper over SQLite with compile-time verification of SQL queries. If a query is invalid, the build fails — better than a SQLiteException at runtime. Room integrates well with Kotlin Flow and LiveData, making reactive UI updates straightforward. The main challenge is schema migrations. @Database(version = N, exportSchema = true) with migration files in assets/databases/ is mandatory; otherwise, fallbackToDestructiveMigration() will simply delete the user's data on app update.

Core Data (iOS) — not a database, but an object graph management framework over SQLite (or XML, or in-memory). NSPersistentContainer with viewContext for reading on the main thread and newBackgroundContext() for writing is the basic setup. The trouble begins when a developer calls save() on viewContext from a background thread: EXC_BAD_ACCESS at a random moment, happens once a week, with almost nothing useful in the crash log. You must use performAndWait or perform for each context strictly on its own thread. Apple Core Data Programming Guide recommends this approach.

Realm wins where you need speed with large object sets and built-in reactivity through Results + observe(). Realm stores objects directly without ORM mapping, so reads require no deserialization. According to our measurements, Realm processes reads 2–3 times faster than Core Data for volumes over 10,000 objects. On Flutter, the Realm SDK (ex-MongoDB Realm) supports Device Sync — but that's a managed service with separate infrastructure.

Hive and Isar are Flutter-specific solutions. Hive is a key-value store, fast, simple, suitable for settings and caches. Isar is a full document-oriented database with indexes, written in Rust, compiled to native code. For Flutter apps with offline functionality, Isar is now preferred: built-in query builder with type-safe filters, transactions, watchObject/watchQuery for reactivity.

Contact us for a free audit of your current storage and optimization recommendations — this will save you hundreds of development hours and up to 60% of server request traffic.

Why Is Offline Synchronization the Hardest Part?

Local storage itself is not complicated. The complexity lies in synchronizing with the server in the presence of conflicts.

The most common pattern is optimistic updates with rollback. The user edits a record, the UI reflects the change instantly, a background request goes to the server. If the server returns an error, we roll back the local state. Sounds simple. In practice: if the user has left the screen and returned before the rollback (which may take 3 seconds), the UX is broken. You need an explicit operation queue with states (PENDING, SYNCED, FAILED) in a separate table.

On Android, for background synchronization we use WorkManager with Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED). Don't forget setInputMerger(ArrayCreatingInputMerger::class) when batching tasks — otherwise, concurrent runs will overwrite data. A typical operation queue implementation:

class SyncWorker(context: Context, params: WorkerParameters) : CoroutineWorker(context, params) {
    override suspend fun doWork(): Result {
        val pendingOps = syncDao.getPendingOperations()
        for (op in pendingOps) {
            try {
                apiClient.send(op.payload)
                syncDao.markSynced(op.id)
            } catch (e: Exception) {
                syncDao.markFailed(op.id, e.message)
                return Result.retry()
            }
        }
        return Result.success()
    }
}

On iOS, the equivalent is BGTaskScheduler with BGProcessingTaskRequest. iOS limitations on background execution time (~30 seconds for refresh tasks) mean that synchronization must be incremental: not "sync everything," but "sync the next N records, save the cursor."

Conflicts in multi-device scenarios are resolved with one of three approaches:

• Last-write-wins based on updated_at (simplest, loses data on concurrent edits)
• Server-wins (client always accepts server version)
• Three-way merge (complex, requires a common ancestor — suitable for documents)

For most B2C apps, last-write-wins with a user-level time vector is sufficient, but for collaborative editing, a CRDTs approach is needed — then look at Automerge or Yjs with mobile bindings.

How We Build the Storage Layer

The repository pattern is not optional — it's mandatory. UserRepository doesn't know where the data comes from: Room, Realm, or network. The ViewModel calls repository.getUser(id), gets a Flow/Stream, and displays data. Caching logic resides inside the repository.

For Flutter, a typical architecture: Isar for persistence, Riverpod for state management, ConnectivityPlus for network status, and a custom SyncService with an operation queue. Riverpod's AsyncNotifier conveniently covers the logic of "show cache, update from network, show new data." Example repository with caching:

class UserRepository {
  final Isar isar;
  final ApiClient api;

  Future<User> getUser(String id) async {
    // try from local storage first
    final cached = await isar.user.where().idEqualTo(id).findFirst();
    if (cached != null) return cached;
    // otherwise from network
    final remote = await api.fetchUser(id);
    // save locally
    await isar.writeTxn(() => isar.user.put(remote));
    return remote;
  }
}

Another important topic is encryption. If the app stores medical data, payment cards, or corporate documents, SQLCipher (Android) and NSFileProtection (iOS) are not optional. Realm supports encryption natively via a 64-byte key that must be stored in Keychain/Keystore, not in SharedPreferences. Skimping on security can lead to data leaks with serious consequences.

What the Work Includes

We guarantee a transparent process and document each stage:

Want to avoid common mistakes when designing storage? Contact us — we'll help design a reliable local storage from scratch or improve an existing one.

Stages of Work

We start with a requirements audit: what data, what volume, is synchronization needed, are conflicts possible. At this stage, it becomes clear whether Core Data or an SQLite-based solution is needed, whether Realm Sync is required or simple REST polling will suffice.

Next, we design the schema with migrations in mind. Schemas change in any project — the question is not "will there be migrations," but "how painful will they be." We export the schema as JSON, store it in the repository, and write tests for each version's migration.

Development includes unit test coverage for the repository layer: network layer mocks, a real in-memory database for query testing. Before release, we profile queries using Android Profiler (Database Inspector tab) or Core Data debug flags (-com.apple.CoreData.SQLDebug 1).

The implementation timeline for a storage layer with basic offline synchronization ranges from 2 to 6 weeks, depending on schema complexity and conflict resolution requirements. Contact us to get a consultation on choosing the optimal stack and migrations.