Offline-First Design for Field Applications
What does offline-first mean?
Offline-first means the application writes data to the device first and sends it to the server afterwards. The user never has to think about connectivity: the record completes locally and synchronisation runs in the background. For an application used in a warehouse, a basement, a rural route or a lift, this is not a feature but a foundational design decision.
A three-part structure
- Local database: the working source of the record lives on the device, and the screen reads from it directly.
- Outbound operation queue: every change is written to a durable queue with its order and its own identifier, surviving app restarts.
- Sync worker: when connectivity returns it sends the queue in order and applies incoming server changes locally.
A screen that calls the network directly is not offline-first; that is an application which shows an error when offline.
The conflict rule cannot be postponed
What happens when two devices edit the same record offline must be written down at the start. Three common strategies: field-level merge, which works well for independent fields such as a stock count and a customer note; last-writer-wins, which is simple but risks data loss and should be limited to non-critical fields; and server authority with a user prompt, which is the correct approach for fields with financial impact such as price, discount or collected amount. The decision belongs at field level — choosing one strategy for a whole table produces either data loss or needless prompts.
Prevent the same record being created twice
On a weak connection the request is sent but the response is lost, the app retries, and two orders appear on the server. The fix is to send every operation with a unique identifier generated on the device, and to have the server return the first result instead of creating a new record when it sees the same identifier again. The API side of this behaviour is detailed in our [API integration guide](/en/blog/api-integration-guide).
Device and store realities
Continuous location tracking drains the battery, so collecting location on events such as visit start and end is enough for most scenarios. Local data cannot grow without limit, so a policy is needed to archive and clear old transactions. Store policies require a justification for location, camera and notification permissions, and the moment of the request should be tied to a step that makes sense to the user. Finally, when the server API version changes, the behaviour of an older client must be defined: show an update prompt rather than fail silently.
Location data is personal data
Employee location is personal data. Collect the minimum needed, write down the purpose and retention period, and inform the employee. Continuous location logging "just in case" creates both legal risk and unnecessary data volume.
Frequently asked questions
Native or cross-platform?
Native has the advantage in scenarios that lean heavily on device hardware — continuous barcode scanning, background location, low-latency camera. For field applications dominated by forms and lists, cross-platform lets one codebase reach both stores.
Does local data need to be encrypted?
Yes, if customer, pricing or collection data is held on the device. Plan for remote session termination and local data wipe in case of device loss.
How should sync completion be shown?
Per-record status — pending, sent, confirmed — is the most reliable method. A single global "synced" indicator hides partial failures.