Offline-first mobile architecture allows selected actions to be captured or completed when the network is unavailable, then reconciles them when connectivity returns. The key word is selected: reading cached instructions, recording a survey and delivering an urgent alert each need a different definition of success.
An application cannot deliver a remote message through a connection that does not exist. It can make local capture durable, show the pending state and attempt delivery when communication becomes possible. Product language and operator behavior should preserve that distinction.
The field constraint behind the design
The humanitarian duty-of-care platform was built for a global staffing organization working in fragile and conflict-affected countries. Its published scope combines employee lifecycle workflows with an offline panic queue, movement-risk approvals, security broadcasts, check-ins and incident reporting.
The platform was built end to end over approximately eighteen months, launched on iOS and Android in 2022 and handed to the client's own team. Those are published project facts. The review methods below generalize the design questions; they do not disclose the client's private protocols or assert an unverified delivery guarantee.
The related field-service ERP case connects mobile field activity to enterprise operations and a client portal. The common architecture question is how an action performed away from a reliable connection becomes an authoritative record that other people can use.
Classify what can happen without a network
Make a workflow inventory before choosing a synchronization mechanism. Some actions can be completed locally, some can be queued and some require a remote decision. A client should not pretend to approve an action whose authority belongs to a server or another person.
| Action | Possible local behavior | Remote boundary |
|---|---|---|
| Read field instructions | Show a cached copy with its age | Confirm whether the copy is still current |
| Record a survey | Save a draft or queued submission | Validate and reconcile the accepted record |
| Request an approval | Capture the request and show it as pending | The authorized party makes the decision |
| Record an urgent alert | Persist the action and show delivery status | A remote recipient can respond only after receipt |
| Update shared data | Capture the proposed change | Resolve conflicts against current authoritative state |
For each action, decide whether data may be stored on the device, how long it remains useful and what the user should do if it cannot be delivered. Some workflows need a separate operational fallback. Software behavior should support that process without making claims about response capability it cannot establish.
Design a durable queue with visible states
A queue item needs an identity, a payload, a creation time and a meaningful state. The exact storage choice depends on the platform and data, but the product questions are consistent: has the action been captured, is it pending, has the server accepted it, or does it require attention?
Do not mark an action as safely captured before the local write succeeds. Consider app termination, device restart, low storage and a user closing the screen immediately after pressing a button. Test the real device behavior. An in-memory list may disappear at exactly the moment the field workflow needs it.
Show a status that matches the evidence. “Saved on this device” and “delivered” are different statements. If the application retries in the background, a user should still be able to inspect pending work. An operator should be able to distinguish a late submission from a new event.
Treat retry as part of the business protocol
A device can lose the response after a server has accepted a request. Retrying without a stable action identity may produce another business action. The server needs a way to recognize the same intended submission and return its status rather than treating every attempt as new.
AWS's idempotent API guidance explains the underlying retry problem. In an offline workflow, the review question is whether the identity survives restarts and repeated delivery attempts, and whether duplicate suppression covers the business effect as well as the transport request.
Retry on appropriate opportunities, including renewed connectivity, but do not assume a network indicator proves the destination is reachable. A captive portal, expired authentication or failing remote dependency can still prevent acceptance. Repeated failure needs a visible state and a way to investigate it.
Define the order of dependent actions. A photograph may depend on an existing survey record; a status update may depend on an accepted request. Either deliver in the required order or make the receiving protocol capable of resolving the dependency. Document what happens when only part of the sequence arrives.
Resolve conflicting updates deliberately
Two devices may edit the same record while disconnected. A simple “last update wins” rule can be acceptable for some preferences and unacceptable for an approval, payroll record or safety status. Choose the rule according to the meaning of the data.
Useful strategies include rejecting a stale version, merging independent fields or presenting a conflict for review. Each has a user-experience cost. Ask who is authorized to decide, what evidence they need and whether the rejected local change remains available.
Device timestamps are helpful context but are not a universal authority for ordering. A device clock can be wrong. Distinguish the time the action was captured from the time the server accepted it, and avoid implying that the two are interchangeable.
Control local data and stale knowledge
Decide which data is necessary for offline work. A full copy of every record may create unnecessary exposure and synchronization effort. Inspect local storage, downloaded attachments, logs and backups as part of the data map, using the actual platform's available controls.
The duty-of-care project's published scope includes sensitive employee information and GDPR controls. That establishes why data handling matters; it does not establish a specific encryption implementation or provide a compliance assessment for a new system. Technical and contractual requirements must be reviewed for the actual deployment.
Cached instructions, permissions and assignments can become stale. Give them a validity policy and a visible age where that matters to the decision. If an action requires current authorization, determine whether offline use is permitted and how a queued action is treated after access changes.
Test the transitions that ordinary demos miss
Run the workflow with connectivity changing at each boundary. Losing the network before sending is a different test from losing the response after server acceptance. Restarting the app with pending work is a different test from keeping it open until synchronization succeeds.
- Capture an action offline, terminate the app and inspect it after restart.
- Deliver the same action repeatedly after simulating a lost response.
- Reconnect with several pending actions and a dependent attachment.
- Attempt delivery after authentication expires or access is revoked.
- Create conflicting updates from two devices.
- Exercise low storage, a full queue and an unavailable remote service.
- Ask a user and an operator to explain the status from the interface alone.
Record the expected business effect and the evidence for each test. The goal is not merely to make the queue empty. It is to establish that the accepted action, operator view and user-visible state agree, or that a disagreement is visible and recoverable.
Scope the field workflow before building
Bring the field action, connectivity conditions, devices and operational fallback into the first discussion. Identify the person who owns the remote decision and the person responsible for pending or failed work. These inputs shape both the product and the synchronization protocol.
A paid architecture scoping week can map those boundaries and define the evidence needed before implementation. Use the review checklist to collect initial inputs. If an existing field app is losing work or showing misleading status, start with the software rescue service and describe the failure.