Offline mobile sync needs agreed conflict rules before development begins. Specify what a user can read or change without a connection, how queued work is identified and what happens when the server has changed in the meantime. A single “last update wins” rule may lose information or apply the wrong business action.
Define decisions by field and operation. Appending a note, replacing a quantity and deleting a record have different consequences. The app should make pending, accepted and rejected work understandable to the user.
List what users may read and change offline
Start with the situations that require offline use. A fictional field-service worker might need a visit summary, a checklist and a way to record work in a building with poor connectivity. Decide which information must be available before the connection is lost.
Use the wider mobile backend architecture to understand where identities, storage and background work fit.
Separate cached reading from offline writing. Being able to view a previously loaded record does not mean the app can safely accept every edit. Some actions may require current server information or a connected approval step.
Android's offline-first architecture guidance discusses local data, synchronisation and conflict resolution. The business rules still depend on the application; a platform pattern does not decide whether one user's change may replace another's.
Define how freshness is communicated. A user should be able to recognise that a schedule or status comes from a previous sync. Avoid a design in which a stale value appears indistinguishable from a newly confirmed server result.
List device and data limits too. Decide how much history is needed, which attachments may be stored and how the app behaves when required data was never downloaded. “Works offline” should describe a bounded set of capabilities rather than an unlimited promise.
Identify records, versions and ownership
Give local records and queued operations identities that remain useful when they reach the server. A newly created offline record may not yet have a server identifier, but the system still needs to recognise the same creation attempt after an interruption.
Define how queued operations are identified and reconciled within the API integration contract.
Record which version or starting state the user edited. A server can then distinguish a change based on current information from one based on an older copy. The engineering team must choose the mechanism; the requirements should explain which business conflicts it needs to expose.
Ownership can differ by field. A worker may own a visit note while dispatch controls the assignment. An offline edit should not gain permission to change the whole record merely because some fields are editable.
Do not assume device clocks establish a reliable business ordering. Define what evidence determines precedence and how uncertain order is treated. The intended outcome should remain explainable when devices reconnect at different times.
Choose rules by field and operation
For notes, preserving both contributions may be appropriate. For a structured status, the business may permit only certain transitions. For quantities, replacing the latest value can erase a separate adjustment that happened while the device was offline.
Work from the operation's meaning. “Add two items” differs from “set the total to two”. If both are represented as a changed number without context, the server may be unable to choose a sensible resolution.
Deletion is a separate policy. Decide whether a stale edit may recreate a deleted record, must be rejected or needs review. A user should receive an understandable result rather than seeing work disappear or an intentionally removed record return.
Where a person must resolve a conflict, give them the relevant versions and consequences. A choice between unexplained “local” and “remote” values can shift an unresolved product decision onto someone who lacks the evidence to make it.
Plan reconnection, duplicates and access changes
Reconnection is a process, not a moment when all work automatically succeeds. Some operations may be accepted, others rejected and others still waiting for a dependency. Keep their states visible and define how related operations are ordered.
A dropped response can leave the device unsure whether the server applied a change. Repeating the same queued operation should encounter the agreed identity and duplicate rules. Creating a fresh operation on every retry can repeat an effect.
Access may change while the device is offline. The server needs to assess the queued operation under the applicable authority when it is processed. Decide what the user sees when a previously permitted edit is no longer authorised.
Also plan the treatment of cached information after sign-out, device handover or access removal. The responsible security and product owners should define the required behaviour. The existence of offline storage does not answer who may continue to read it.
Use the conflict decision table
The following hypothetical cases illustrate different decisions. They are not validated sync behaviour for a released app.
| Situation | Question to agree | Possible rule to review |
|---|---|---|
| Two workers edit the same note | Are they replacing text or contributing separate observations? | Preserve both or use an explicit merge process |
| An offline quantity meets newer server activity | Would replacement erase valid work? | Reconcile the operation rather than blindly overwriting |
| A record is deleted while a device edits it | May the edit recreate it? | Reject or route for review under the chosen policy |
| Access is revoked before reconnection | Is the queued change still authorised? | Recheck authority and communicate the rejected result |
For the fictional field-service visit, follow a note and a completion action separately. The note might be preserved while completion is held because the assignment changed. That outcome can be legitimate if the user understands it and someone owns the unresolved work.
Acceptance should include repeated sync, partial success, an app restart and a stale record. Check both device and server evidence. A disappearing spinner does not establish that every business operation was accepted.
Walk through a rejected offline operation from the user's perspective. The fictional worker completes a visit while disconnected, but dispatch has reassigned it before reconnection. The server rejects the completion under the agreed rule. Decide whether the worker can still retain a local note, who receives the unresolved case and how the interface distinguishes saved work from accepted completion. A generic sync error gives too little direction.
Do not remove queued evidence merely because the app has displayed a warning. The workflow needs a defined closure action and appropriate retention arrangements. Equally, preserving an operation for review should not cause it to be retried indefinitely after a final rejection.
Agree the sync contract before app development
Bring product, operations and engineering owners together to review the conflict table. Confirm the offline boundary, identities, field rules, access changes and user messages before implementation estimates assume them.
The contract should make difficult cases visible without forcing every conflict into a generic overwrite policy. That gives users a clearer account of their work and the support team a route to resolve the cases automation cannot safely decide.
Discuss offline mobile app requirements with ZakCodeX before sync behaviour becomes an implementation assumption.
