Offline-First Sync Conflicts in Mobile Apps

Name the conflicts users will actually hit

Not every collision is a merge problem. Some are duplicate intents: tap 'pay' twice on a flaky tunnel, queue two transfers, and reconcile when connectivity returns. Others are true edits to the same field from two devices. Your sync layer needs separate strategies—idempotency keys for actions, structured merges for state.

Staff teams document conflict classes per entity: append-only events, scalar fields with LWW, set unions, and 'human required' merges. If product cannot describe the desired outcome, engineering should not guess in the client.

Prefer boring server rules with honest client UX

Last-write-wins is fine for low-stakes preferences; it is unacceptable for money, inventory, or medical notes without escalation. Expose server merge results with provenance: which device won, what was discarded, and how to undo when policy allows.

Queue mutations with client-generated ids and retry-safe APIs. The server should recognize duplicates and return the original outcome instead of double-applying side effects.

• Idempotency keys on every user-visible mutation
• Per-entity conflict policy documented with product sign-off
• Conflict screens that show both versions, not silent overwrite
• Sync backlog metrics: queue depth, age, and failure rate by OS version

CRDTs when collaboration is the product

When multiple users edit shared artifacts in real time—whiteboards, shared lists, co-editing notes—CRDTs or operation-based OT can beat naive timestamps. The cost is complexity, testing burden, and harder support narratives. Adopt when offline collaboration is core value, not because the blog post sounded cool.

Even with CRDTs, you still need authorization, compaction, and snapshot boundaries so clients do not replay unbounded history on cold start.

Prove sync health outside the lab

Simulate airplane mode, clock skew, partial uploads, and app kills mid-queue. In production, sample conflict rates, merge failures, and user undo actions. Spikes after a release often mean a schema or policy change—not 'users offline more.'

Offline-first is a reliability feature. Treat sync like payments: observable, owned, and rehearsed before marketing promises it everywhere.

• Automerge — CRDT library
• Apple — Syncing model data
• Couchbase — Mobile sync