Build the field app for the worst signal it will ever see

Offline is the normal state

An offline-first application is not an online application with a cached fallback. The local store is where the app reads and writes, and the network is a background process that reconciles it with the server when it can. That inversion has to be made at the start, because it is the data model rather than a feature.

The device holds the truth

Until a record has been accepted by the server, the copy on the phone is the only one that exists. It has to survive the app being killed, the battery dying and the operating system reclaiming memory, which means a real database on the device — SQLite through whatever React Native or the platform offers — and not state held in memory.

Writes go to a queue

Every change a person makes is written locally at once and appended to a durable outbox. The interface never waits for a response, and the queue drains whenever a connection appears.

local.write(record)
outbox.append(change)

Retries need a backoff, and every operation needs to be safe to send twice, because the failure that matters is the one where the server accepted the write and the reply never arrived.

Identifiers are made on device

A record created offline needs an identity before the server has seen it, so the client generates it — a UUID, not a sequence. Server-assigned keys force a round trip that by definition is not available, and every workaround for that becomes a mapping table nobody maintains.

Conflicts need a rule

A conflict resolved by asking the user is a conflict handed to whoever is least equipped to decide, at the worst possible moment.

Two people editing the same job is rare and inevitable. Pick the rule in advance and write it down: last write wins on this field, the server wins on that one, and a real collision on a signed-off record becomes a task for the office rather than a dialog on a wet phone.

Show the sync state plainly

The person using it needs to know what has reached the server and what has not. Per-record state — saved on device, sending, accepted — is honest. A spinner is not, and an app that has been quietly queueing for six hours is how a day of work gets lost.

Photographs break the model

Attachments are where offline designs usually come apart. A shift of full-resolution photographs will not fit in a queue that was sized for form data, and it will not go up over a weak connection either.

• compress on the device, before queueing
• upload attachments separately from records
• resume a part-finished upload rather than restart it

Storage on the device is finite, so the app also needs a rule for when a photograph that has been accepted may be deleted.

Test it in aeroplane mode

Every test that matters starts by turning the network off, doing a full shift of work, killing the app, turning the network back on, and checking that nothing was lost and nothing arrived twice. Anything less tests the code that was easy to write.