For custom mobile apps, the right approach combines an offline-first local canonical store, optimistic conflict handling using CRDT-style merging where it fits, and hybrid real-time delivery: WebSocket for active sessions, APNs or FCM for background devices. Tools like Automerge make automatic merging practical, and we at Pocket App build this pattern into client projects because it balances availability against data integrity.
TL;DR:
- Offline-first local stores should be used with optimistic merging, especially CRDTs, for collaborative features with high availability needs.
- Conflict resolution modes like last-write-wins, merge-accept-yours, or fail-on-conflict must be chosen based on data type and user impact, with custom resolvers preferred.
- Hybrid real-time delivery combines WebSocket for active devices and push notifications for background or offline devices, requiring dual delivery and deduplication.
- Telemetry should track sync success, queue depth, duplicate alerts, and conflict failure rates to optimize performance and user experience.
- Clear scoping of conflict policies and delivery tiers before development reduces conflicts, operational costs, and improves predictability of sync behavior.
Table of Contents
- 1. Architectural patterns: offline-first, replica models and when to choose them
- 2. Conflict detection and resolution: concrete modes and UX implications
- 3. Real-time and offline delivery: hybrid model, buffering and deduplication
- 4. Implementation checklist, telemetry and cost trade-offs for product owners
- 5. Our perspective on scoping and delivering mobile sync in client projects
- Next steps: talk to us about your sync requirements
- FAQ
- Sources
1. Architectural patterns: offline-first, replica models and when to choose them
Most sync failures in commissioned apps trace back to one decision made too late: whether the server or the device holds the canonical copy of the data at any given moment. Get this wrong and every other sync decision becomes a patch on a shaky foundation.
The offline-first repository pattern treats the local database as the default read source, with the network acting as a separate, asynchronous write-back channel. Android's offline-first guidance recommends exactly this: local data is canonical for reads, and a repository layer mediates between what is on the device and what eventually reaches the server. The user never waits on a network call to see their own data.
This choice forces a second decision: optimistic or pessimistic replication. Optimistic replication lets a device accept local writes immediately and reconcile later, which keeps the app responsive even on poor connections. Pessimistic replication locks a record before anyone can edit it, which avoids conflicts entirely but punishes the user with waiting states and failed locks whenever connectivity drops. Enterprise architecture guidance generally favours optimistic strategies for availability, reserving pessimistic locks for transactions where a conflict would be genuinely costly, such as financial transfers or inventory holds.
Conflict-free replicated data types, or CRDTs, sit at the automatic end of optimistic replication. Crdt describes them as structures that merge concurrent updates without user intervention, which suits decentralised or peer-to-peer apps well. Automerge is the most widely used practical implementation: Martin Kleppmann's research shows a JSON CRDT model built specifically for offline edits and automatic merging across devices.
When scoping a project, we generally recommend:
- Optimistic offline-first with CRDT-style merging for collaborative or high-availability consumer features, such as shared lists or notes.
- Server-authoritative models with pessimistic locking reserved for transactions with real conflict cost, like bookings or stock adjustments.
2. Conflict detection and resolution: concrete modes and UX implications
Once two devices edit the same record offline, something has to decide which version wins. The decision you make here shows up directly in your users' experience, so it belongs in the brief, not left to whoever writes the sync code.
Four merge modes cover most practical cases. Last-write-wins simply keeps whichever edit has the latest timestamp, which is fast but silently discards the other change. Merge-accept-yours favours the local device's version on conflict. Fail-on-conflict rejects to write and returns the record to the client for manual resolution. Overwrite replaces the remote record entirely, which is rarely safe outside single-owner data.
Couchbase's conflict handling documentation confirms that last-write-wins is the common default in replication systems, but notes that production apps should implement custom resolvers rather than rely on the default behaviour. Salesforce's Mobile SDK guide describes the three-way pattern that underpins most of these modes: a base version, the server's "theirs" version, and the device's "yours" version, with the API returning all three plus the remote and local changes when a conflict fails.
The UX question is when to surface a conflict to the user versus resolving it silently. CRDTs make silent, automatic resolution possible because the merge is mathematically guaranteed to converge. Anything without that guarantee, including last-write-wins on free-text fields, risks losing a user's work without them knowing, so fail-on-conflict with a clear merge prompt is often the safer default for anything the user would notice missing.
Pro Tip: Set a maximum acceptable conflict-failure rate (for example, under 1% of sync attempts) as an explicit acceptance criterion before development starts, not as something discovered in testing.
Acceptance criteria worth writing into the brief:
- The conflict strategy per data type (CRDT merge, last-write-wins, or fail-on-conflict).
- The fallback behaviour when automatic resolution cannot determine a winner.
3. Real-time and offline delivery: hybrid model, buffering and deduplication
A device that is open and connected needs a different delivery mechanism to one that is asleep in a user's pocket, and treating them the same is where most sync designs quietly break.
Websocket sets out the hybrid model clearly: WebSockets (or server-sent events) deliver instant updates to devices that are actively connected, while push services such as APNs, FCM and Web Push wake devices that are backgrounded or offline. Neither channel alone is reliable. A WebSocket connection can appear alive while the OS has throttled the app in the background, and push delivery can be delayed or rate-limited, so critical messages need dual delivery with deduplication to avoid confusing the user with the same alert twice.
**FCM push delivery is commonly rate-limited, so WebSocket.org recommends treating push as a wake-up mechanism rather than a guaranteed transport for high-frequency updates.
AWS's guidance on real-time apps reinforces this by treating the WebSocket channel as a non-authoritative trigger: when the app returns to the foreground, it should always perform an authoritative fetch from the sync endpoint rather than trusting whatever arrived over the socket while it was away.
Building the hybrid model well means addressing four things in order:
- Presence tracking: know which devices are actively connected so you can route messages to the fastest available channel.
- Priority tiers: classify messages as critical, important or informational, and dual-deliver only the critical tier.
- Server-side buffering: hold a bounded queue (last N messages or last T minutes) so a reconnecting device can replay what it missed, using Redis for speed or PostgreSQL or DynamoDB where durability matters more than latency.
- Deduplication: assign every payload a unique ID, keep a short-lived "seen" cache on the client, and coordinate across open browser tabs using the BroadcastChannel API so the same alert does not fire twice.
Our push notification strategy guide covers how these delivery tiers map onto engagement goals, which is worth reading alongside the technical design.
4. Implementation checklist, telemetry and cost trade-offs for product owners
Procurement teams rarely need the full engineering detail, but they do need a list of deliverables precise enough to hold a development partner to account.
At minimum, the brief should specify: durable local writes that survive an app restart, a defined sync endpoint, conflict metadata attached to every record, a queued retry mechanism with backoff, and a stated replay window for reconnecting devices. On Android, WorkManager is the standard mechanism for this queued retry behaviour, pairing network monitoring with exponential backoff so a failed sync does not hammer the server or drain the battery.
Three decisions belong in the documentation, not left to interpretation mid-build: the conflict strategy per data type, the buffer retention policy (expressed as a message count or a time window), and which message tiers require guaranteed delivery versus best-effort.
Telemetry worth tracking from day one:
- Sync success and failure rate, with failure spikes investigated immediately.
- Queue depth and replay latency on reconnect.
- Duplicate-alert rate, which signals a deduplication gap.
Pro Tip: Tie buffer retention size and background sync frequency directly to your SLA: a longer retention window costs more in storage but reduces the chance a user misses a critical update while offline.
5. Our perspective on scoping and delivering mobile sync in client projects
Across numerous projects spanning retail, charity and healthcare, we have found that sync problems are almost always scoping problems first and engineering problems second. Our discovery process maps every critical data type before a line of sync code is written, and conflict and priority policies are agreed with the client as an explicit deliverable rather than an assumption buried in a technical spec.
That early agreement pays off later. Projects that define their conflict strategy upfront consistently see fewer conflict failures in production, more predictable replay behaviour on reconnect, and operational costs that match the forecast rather than drifting as usage grows. It is the single highest-leverage conversation to have before development starts.
— Paul
Next steps: talk to us about your sync requirements
If you are commissioning a custom app with offline or multi-device requirements, the earliest and cheapest point to get the sync architecture right is before development starts, not after a round of bug reports. Our Discover, Design, Develop and Deploy process is built to map these decisions early, and for product owners who just need a sense check before committing to a full project, a Mobile App Clinic gives you rapid, focused advice on your sync design.
What that conversation typically covers:
- Which data types need offline-first canonical storage versus server-authoritative handling.
- Whether your use case needs CRDT-style automatic merging or a simpler fail-on-conflict policy.
- How push and real-time delivery should be tiered for your specific alert types.
Get in touch through our business app enquiry page to start scoping your project.
FAQ
What is mobile data sync in a custom app context?
Mobile data sync is the set of architectures and techniques that keep app data consistent between a device and a backend server, covering offline storage, conflict resolution and real-time or background delivery. It is distinct from consumer features like phone backup, since it concerns how custom-built apps maintain data integrity across devices.
Should I use WebSockets or push notifications for sync?
Use both: WebSocket connections deliver instant updates to devices that are actively open, while push services like APNs and FCM wake devices that are backgrounded or offline. Relying on only one channel leaves either active or sleeping users without reliable delivery.
What is a CRDT and when should I use one?
A CRDT, or conflict-free replicated data type, is a data structure that merges concurrent edits automatically without needing a user to resolve the conflict. They suit collaborative or offline-first features where automatic, decentralised merging matters more than a single authoritative server copy.
How do I choose a conflict resolution strategy?
The right strategy depends on the data: low-stakes fields often work fine with last-write-wins, while anything a user would notice missing benefits from a fail-on-conflict policy with a visible merge prompt. Couchbase's conflict documentation recommends defining custom resolvers rather than relying on replication defaults.
What does Pocket App charge for a sync-enabled app build?
Pricing depends on project scope and is agreed during our Discover phase, so there is no published fixed rate. A Mobile App Clinic is the quickest way to get a sense of scope and cost for your specific requirements.
Sources
- Websocket
- About CRDTs • Conflict-free Replicated Data Types
- Automerge: Real-time data sync between edge devices
- Offline-first data layer guidance (Android Developer)
- Couchbase Lite conflict handling documentation