Your field app should survive a lost connection

A technician finishes an inspection in a basement, taps Save, and watches the spinner. The signal drops. When the app opens again, the inspection is empty. A connection problem has become thirty minutes of repeated work.

Offline behavior belongs in the design of a field app. Decide what the device can save, what requires a server decision, and how the person using it will know the difference.

Ink & Switch's 2019 paper Local-first software describes offline operation and local ownership as goals of a broader software architecture. An existing business app can improve its offline behavior without adopting every part of that architecture.

Give saved work an honest status

Use separate states for saved on this device, waiting to sync, synced, and needs attention. A single checkmark is ambiguous if the office cannot see the record yet.

Persist the draft before showing the local-save confirmation. Keep the status available after navigation and reopening the app. If the upload fails, retain the work and give the user an action that explains what happens next.

The boundary depends on the action:

Action	Useful offline behavior
Inspection notes	Save a local draft and queue its changes
Photos	Retain the file and its association with the inspection until upload is confirmed
Reference documents	Show permitted cached copies with a freshness indicator
Appointment reservation	Save a request; show confirmation only after the server accepts it
Payment	Follow the payment provider's supported offline behavior and requirements

Do not label a requested reservation as booked. Another device may have taken the slot while this one was disconnected.

Queue operations with stable identities

Assign an identity to each intended operation and preserve it across retries. Reconnecting should resume the same upload or submission, rather than create a new business action each time.

AWS's guidance on idempotent APIs explains why identifying the caller's intended request matters when retrying. Apply that principle to the receiving endpoint as well as the device queue.

Store enough state to recover if the app closes after the server accepts a change but before the device receives confirmation. Where the remote service supports it, reconcile using the operation identity. A fresh request with a fresh identity can produce a duplicate.

Decide how conflicting edits work

Suppose the office changes an appointment while a technician edits the same record offline. Replacing the whole server record with the device's older copy can erase the office's change.

Choose conflict rules by field and consequence. Independent notes can often remain separate entries. Conflicting appointment times need a decision. Use record revisions or another concurrency mechanism to detect incompatible updates, and show the competing values when a person needs to resolve them.

Also decide what belongs on the device. Cache only the records the user needs and may access. Plan for encryption, logout, shared devices, and lost devices. An offline cache is still a copy of business data.

Test interruptions in the middle

Start an inspection, switch to airplane mode, add a photo, and close the app. Reopen it before reconnecting. Then restore the connection while another user changes the same record.

Inspect both the device and the server. Confirm that the draft survived, attachments belong to the right job, the queue drains once, and conflicts remain visible. Repeat with logout during a pending upload and with a server error after reconnection.

The acceptance test is simple to describe: the technician can tell what was saved, the office can tell what arrived, and neither has to guess whether repeating the action will make things worse.