Offline-First Mobile Architecture:The 2026 Guide to Sync Engines, CRDTs, and Life After Realm Sync

"We need offline support" means at least three different things, and conflating them is where a lot of these projects go wrong before a line of code is written. Offline-first, as this guide uses the term, means a user can both read and writedata with no network connection at all — the app's normal write path is "save locally, sync when possible," not "call the server, and cache the response in case the next read has no network." That's a meaningfully bigger architectural commitment than read-only caching, and most teams asking for "offline support" actually mean the smaller thing.

If you're still deciding on a cross-platform framework before any of this becomes relevant, our cross-platform development guide covers the React Native/Flutter/native tradeoff more broadly — every sync engine in this guide has React Native and iOS/Android-native bindings, but which framework you've already committed to narrows the realistic shortlist.

This isn't a ranked top list — the right engine depends entirely on which backend you already run and how much concurrent-write complexity your data model actually has, which is a fit question, not a benchmark question. What it is: a status check on the players that matter in 2026, since corporate status in this category has moved more in the last eighteen months than in the prior five years combined.

One structural point worth flagging before the next two sections, both of which are about corporate risk specifically: two of the nine rows above changed status within the last thirteen months (Realm's sync shut down entirely; Electric got acquired), and a third (Replicache) was formally superseded by its own maker. A sync engine is core, hard-to-swap infrastructure — treat a vendor selection here with the same scrutiny you'd apply to a database choice, not a UI library choice.

Realm was, for years, one of the most widely adopted mobile embedded databases, and its automatic cross-device sync was the single biggest reason teams chose it over a plain SQLite wrapper. MongoDB acquired Realm in 2019 and rebranded the sync service Atlas Device Sync, paired with Atlas Device SDKs. In September 2024, MongoDB announced Device Sync's deprecation; the service shut down completely on September 30, 2025.

What survives: the Realm SDK itself, as a purely local, non-syncing embedded database, remains available and open source from v20 onward — a real, usable piece of software, just missing the half that made Realm distinctive. Community discussion of the shutdown, including a widely-read GitHub discussion titled "The Future: Realm is Deprecated/Dead", reflects how many teams treated managed sync as a permanent platform capability rather than a product line MongoDB could discontinue on its own schedule.

This isn't the first time this exact lesson has shown up on this site. Our deep linking implementation guide makes the identical point about Firebase Dynamic Links, which shut down completely in August 2025 — a free or bundled infrastructure feature from a major platform vendor is not exempt from being discontinued on that vendor's own timeline, and sync engines specifically have now demonstrated this twice in the same eighteen-month window.

Electric (the company behind ElectricSQL) announced on August 11, 2026that it is joining Databricks, folding into the team building Neon and Lakebase — Databricks' Postgres-centered platform, following its roughly $1 billion acquisition of Neon in May 2025. Unlike Realm, this isn't a full shutdown: Electric has stated that everything it previously open-sourced — Postgres Sync, PGlite, TanStack DB, and Durable Streams — stays open source.

One technical caveat worth stating separately from the acquisition, since it's easy to conflate the two: Electric has always been a read-path sync engine — it streams Postgres data out to clients via shape subscriptions, but provides no built-in mechanism for getting local writes back into Postgres. Teams typically pair it with TanStack DB's mutation layer or a hand-rolled write API for the other half. That limitation predates the Databricks announcement and isn't a consequence of it; it's a standing architectural fact to weigh regardless of who owns the company.

Every offline-first architecture eventually answers the same question: when two devices each changed the same data while disconnected, what happens when they reconnect? Last-write-wins (LWW) keeps whichever edit has the later timestamp and silently discards the other — simple, and often good enough, but it means a user's work can vanish with no notice. A CRDT (Conflict-free Replicated Data Type) is a data structure engineered so concurrent edits merge deterministically without a central arbiter, preserving both changes instead of picking a winner.

Yjs and Automerge solve overlapping but distinct problems: Yjs has the deeper editor-ecosystem integration and is the more common production default, while Automerge's appeal is treating your data like plain JSON with a Git-like change history baked in. Automerge's 3.0 release in July 2025 was a genuine step change, not an incremental one — re-architecting the runtime around columnar compression cut memory consumption roughly tenfold for text-heavy workloads compared to 2.0. Neither library, on its own, correctly handles formatted rich text (bold, italics, links) merging when two people format the same passage differently offline — that specific problem is what Peritext, a published Ink & Switch/CSCW 2022 algorithm, was built to solve, by storing formatting as spans tied to stable character identifiers rather than raw positions.

The order matters because each step depends on the one before it, or fails invisibly without it — the same pattern that governs push notification and deep-linking infrastructure on this site applies here, with offline-sync's own specific failure modes swapped in.

The outbox — step 2 — is the load-bearing piece most teams underbuild. It's a durable local queue that records the intent of a write synchronously, before the network call is even attempted, so the intended change survives an app kill or a power loss mid-write. A dispatcher then drains it on app start, on connectivity restore, on app resume, and once eagerly right after the write is enqueued — removing each entry on success, leaving it in place on a transient failure like no network, a server 5xx, or a timeout.

A dispatcher that only runs while a user is actively looking at the app defeats much of the point of offline-first — but both mobile platforms are far stingier about background execution than most teams building this for the first time expect.

On iOS, the BackgroundTasks frameworksplits background sync into BGAppRefreshTask (short refresh work) and BGProcessingTask (longer jobs the system runs opportunistically, typically when the device is idle and charging). Apple's own documentation is explicit that it doesn't guarantee your requested interval — the system decides when to actually run your task based on the user's usage patterns, current battery state, and expected battery impact. Implementation guides commonly report a practical execution budget around 30 seconds for a refresh task before the OS terminates it, and widely documented developer experience holds that a user force-quitting the app stops iOS from scheduling further background tasks for it at all — treated as an explicit "don't run this unattended" signal from the user.

On Android, WorkManageris the Jetpack-recommended API for work that must survive process death, app restarts, and device reboots — the standard choice for draining an offline write queue. Google's guidance splits background work into three categories: immediate/expedited, long-running (potentially over ten minutes), and deferrable/periodic — and deferrable work respects Doze mode and battery optimization by design, meaning the OS can and will delay it to preserve battery rather than run it on your requested schedule.

The point of local-first's "fast" ideal is that a write feels instant — the UI updates optimistically the moment a change is queued to the outbox, without waiting on a network round trip. Done well, that's the whole appeal of offline-first over a thin client. Done carelessly, it becomes a way to quietly mislead users about whether their data is actually safe.

• A spinner that never resolves: A generic loading indicator with no distinct state for "queued locally, not yet synced" leaves a user unable to tell whether it's safe to close the app or switch devices after days offline.
• A premature "saved" confirmation: Firing a success toast the instant a write hits the local outbox, with no later correction if the sync ultimately fails (a rejected write, a validation error caught server-side), teaches users to distrust the app's own status messages the first time it happens.
• Unbounded local queue growth: Letting the outbox grow indefinitely with no visible cap, warning, or storage policy turns a temporary connectivity gap into a silent, unbounded liability the user never sees coming.

The fix pattern is an explicit sync-status state machine surfaced to the user — synced, pending, conflict, failed — rather than a binary spinner. And when a CRDT or last-write-wins policy actually resolves a conflict, that resolution deserves a visible trace: "your change to this field was combined with a later edit from [teammate]" treats the user as someone whose work matters, where silent overwrite treats a merge as an implementation detail nobody needed to know about.

An offline-first app keeps a meaningful, often complete, copy of user data sitting on the device by design — which raises the stakes of local storage security compared to an app that's mostly a thin client over a server with nothing persisted locally.

The standard defense is encryption at rest for the local database — SQLCipher-style encryption for SQLite, or relying on platform full-disk encryption plus per-file protection classes — combined with storing the actual encryption key in the OS-level secure key store rather than embedding it in app code. Our biometric authentication guide covers how the Secure Enclave-backed Keychain (iOS) and Keystore (Android) actually work in more depth — the mechanism is identical whether you're protecting a biometric-gated secret or a local database encryption key.

There's a genuine, unresolved tension worth naming honestly rather than glossing over: Kleppmann's "privacy" ideal calls for end-to-end encryption, but a server-side CRDT merge process typically needs to read the data it's merging. Fully end-to-end-encrypted multi-writer conflict resolution is an active area of research, not a solved, off-the-shelf capability most 2026 sync engines actually deliver — treat any vendor claiming otherwise with the same skepticism this site applies to an unverified security claim anywhere else.

Hand-rolling — a client-side database like WatermelonDB or RxDB paired with your own outbox, idempotency, and last-write-wins logic — is defensible when your data is effectively single-writer-per-record: a technician closing their own job ticket, a user editing their own profile, with true simultaneous conflicts rare enough that a simple resolution policy and a visible "last updated by" trail cover it adequately.

A vendor earns its fee once your app has genuine concurrent multi-writer editing you don't want to build correctness guarantees for yourself, cross-platform consistency across web, iOS, and Android on one sync layer, or — Ditto's specific niche — sync between devices with no server reachable at all, not just a phone with weak signal. None of the vendors in this guide's landscape section remove your own obligation to design the outbox, idempotency, and conflict-surfacing UX layers described above; they replace the sync transport and merge algorithm, not the whole architecture around it.

If you're scoping this alongside a broader cost conversation, our app total cost of ownership guide covers how a sync engine's licensing model (open-source self-hosted vs. a managed vendor's recurring fee) plays into a five-year cost picture beyond the initial build.

The following is an illustrative worked scenario, not a real client engagement or a reported outcome — the arithmetic uses stated, realistic assumptions to make the cost of a missing idempotency layer concrete.

Consider a 60-technician HVAC and plumbing service company running a field app that lets technicians log completed job tickets, parts used, and customer signatures without a live connection — since a meaningful share of calls happen in basements, rural service areas, or buildings with poor in-building coverage. Assume the company's own dispatch data shows it completes roughly 600 job tickets a day fleet-wide, and that roughly 12% of those closeouts happen somewhere with degraded or no connectivity.

The honest reading of that table isn't that a missing idempotency layer is a catastrophe — most duplicate tickets get caught eventually. The point is that this class of bug is silent by design: nothing crashes, no error surfaces to the technician, and the only visible signal is a bookkeeping team quietly reconciling a small, recurring stream of duplicate parts-invoice line items that looks, from a dashboard, indistinguishable from normal data-entry noise until someone specifically audits for it.

If you're evaluating competing proposals for a broader app rebuild that happens to include offline sync as one piece, our mobile app RFP template guide covers how to write scope language specific enough that different agencies' "offline support included" claims are actually comparable, instead of each one claiming the feature at very different levels of rigor — the same principle this guide's red flags apply to deep linking and push infrastructure elsewhere on the site.

One scoping note specific to this domain: the discovery phase should always include an explicit write-concurrency audit of your actual data model — which records genuinely get edited by more than one actor concurrently, and which don't — before a sync engine or conflict-resolution strategy gets chosen. Picking a CRDT-based engine for data that's effectively single-writer wastes complexity budget; picking last-write-wins for data with real concurrent edits loses user work silently.

None of this replaces testing your own sync engine choice against your actual data model, write patterns, and device population — this guide can only describe the current state of a fast-moving category as of the date it was checked, not guarantee it hasn't shifted again by the time you read it. Given how much has already changed in eighteen months, treat that as a real possibility, not a formality.