Summary. An offline sync engine lets a mobile application keep working with no network by reading and writing a local database, recording every outbound change in a durable queue, and reconciling with the server through delta synchronisation when connectivity returns. The hard parts are not the happy path — they are dependency ordering on replay, conflict handling, attachment durability, and the initial synchronisation of a large dataset onto a new device.
What problem this solves
Field work happens where networks fail: basements, warehouses, plant rooms, rural routes, lifts. An application that requires connectivity does not degrade gracefully there — it stops, and the user falls back to paper, which is the outcome the software was bought to prevent.
The requirement is stricter than "handles a dropped request". Work captured offline must survive the app being closed, the battery dying and the device restarting, because hours can pass between capture and reconnection. Data held in memory, or in a retry loop inside a running process, is not offline support — it is a delay before data loss.
The architecture
The four mechanisms that carry the weight
Local database. The application reads and writes a database on the device. The interface never waits on a network call, which means the offline case is not a degraded mode — it is the normal mode, and connectivity is an optimisation. This is the decision that determines everything else: an app that treats the server as its read path can never be genuinely offline-first, however much caching is added later.
Durable outbox. Every change is appended to a persistent queue before it is acknowledged to the user. Durability is the whole point: if the process dies, the queue survives. This is the difference between "we will try to send it" and "it will be sent".
Delta synchronisation. Only what changed since the last successful sync moves in either direction, with a checkpoint per device. Re-downloading the world on every sync becomes unusable once a dataset is real, and it burns the battery and data allowance of the person least able to spare either.
Dependency ordering. Queued changes replay in an order that respects their relationships — the visit before the order it produced, the customer before the invoice raised against them. Without it, replay fails on records the server has not seen yet, and the failures look random.
Conflict handling is a business decision
When the same record changed on the device and on the server, something has to give. The available rules — last write wins, server wins, client wins, field-level merge, or explicit user resolution — are all defensible, and none is universally correct.
What is not defensible is discarding the losing version silently. A rep who recorded something and later finds no trace of it loses confidence in the entire application, and that confidence does not come back. The losing version should be visible even when it is not applied.
The practical mitigation is to reduce the number of genuine conflicts rather than resolve them cleverly: field-scoped ownership, append-only transaction models, and giving each device its own working set all shrink the surface where two writers meet.
Attachments are work, not decoration
Photographs are the most commonly mishandled part of an offline system. They are large, they are captured in exactly the conditions where upload fails, and they are frequently treated as a side effect of the record rather than as queued work in their own right.
If a photo lives only in a temporary directory and the record syncs without it, the evidence is gone and the record looks complete — the worst combination. Attachments belong in the same durable queue as the records that reference them, with their own retry and their own completion state.
The two hardest operational problems
Initial synchronisation. A new device has nothing, and it lands at the worst possible moment — a new user's first launch, often in a training room on shared wifi. The mitigations are selective sync (hold only the subset this user needs: their outlets, their jobs), progressive availability so the app becomes usable before the sync completes, and resumability so an interrupted first sync does not restart from zero.
Recovery. Devices are lost, wiped and replaced. If un-synced work exists only on a device that is now at the bottom of a canal, it is gone — which argues for syncing opportunistically and frequently rather than in scheduled batches, and for making the un-synced queue depth visible to the user rather than hiding it.
Failure modes worth designing for explicitly
- Partial connectivity — a network that exists but times out is worse than no network, because naive retry logic hangs the interface. Treat slow as offline.
- Clock skew — device clocks are wrong, sometimes by years. Never resolve conflicts on device timestamps alone.
- Poison messages — one queued change the server will always reject blocks everything behind it. The queue needs a way to quarantine an item and keep draining.
- Silent divergence — a device that believes it is in sync and is not. Periodic reconciliation of a checksum or a record count catches this; nothing else will.
How xMatix implements it
The xMatix mobile app is a native, offline-first application over a local database, with delta synchronisation and a durable outbox for outbound work. Writes are recorded locally and acknowledged immediately, then replayed with dependency ordering when connectivity returns, so chains of related records — a visit, the order it produced, the payment collected against it — reconstruct correctly on the server.
Photographs captured during a visit are preserved as durable work and uploaded on reconnection rather than being lost when a visit is closed offline. Conflict handling is explicit, and captured work is not discarded silently.
The same engine carries the whole field surface: visits and activity checklists, order capture, van load and unload, payments, geofenced attendance and background GPS trails. Screens designed in the studio render natively on the device, so changing a form does not require an app-store release — which matters for an offline app, because a device that is rarely online is also a device that rarely updates.