Offline field applications

Close the app after the server accepts the report

The hardest offline test is a successful server write with no receipt on the phone. Reopening must recover that result without submitting the work twice.

In this article

Prepare a report you can identify at both ends

Use a synthetic inspection with a unique command ID, a known base revision and two small test photographs. Record the local queue entry and the corresponding server lookup method. A screenshot of the success screen alone will not prove how many reports were created.

Run the test on the supported device and browser combinations. Desktop network throttling is useful during development, but it does not reproduce every mobile suspension and storage behaviour.

Start with an ordinary successful sync so the team knows the expected records and cleanup state. Then introduce one failure at a time.

Lose the response after acceptance

Arrange for the server to commit the report while the client receives no usable response. Close and reopen the application before another attempt. The phone should still have enough information to ask about the original command.

Resume synchronisation. Expect one business report, the same command identity and a recovered receipt. Two HTTP attempts are acceptable. Two completed inspections are not.

Repeat the case after an attachment upload but before report acceptance. The report should recover its uploaded file reference, or repeat the transfer safely, without presenting an orphaned photograph as evidence of completion.

Change the office record while the phone is offline

Edit an office-owned field after the device has downloaded revision seven. Submit the device's work against that older revision. Confirm that the application either applies a documented field-level merge or stops at a comprehensible conflict screen.

The technician's notes must remain available while they review the difference. Choosing the office version should not accidentally discard unrelated observations or attachment references.

Also expire the session before reconnection. The queue should wait for authentication and must not attach the pending report to a different account that signs in next.

Test the storage failure users cannot fix with Retry

Force a local write failure in a controlled test environment. The save action must report that the draft was not durably stored. Test an application upgrade with pending entries as well as a normal restart.

Capture local state, server state and the visible message for each case. A passing result explains where the only copy lives at every interruption point. That evidence is more useful than a claim that the app works in airplane mode.

Primary sources

MDN: browser storage quotas and eviction

References checked 11 September 2026.