Offline app design: what happens after the connection returns?

An offline-capable app needs a clear answer to a customer’s most important question: “Is my work safe, and has anyone else received it?” A screen that remains visible without a connection answers only part of that question.

Reliable offline behaviour begins with product rules. Decide which information can be viewed, which changes can be saved locally and which actions require confirmation from the server. Then design the interface and synchronization around those rules.

Define offline capability one action at a time

A product does not need to treat every action identically. A technician might read a downloaded job, draft notes and capture photographs offline, while a final stock reservation requires a live server check.

Flutter’s offline guidance distinguishes reading from local data, online-only writes and writes saved locally before synchronization. Each has different consistency tradeoffs. Flutter offline-first guidance

For each important action, record:

• What data must already be downloaded?
• How old can that information be before it becomes misleading?
• Can the action be saved locally?
• Does it affect a scarce resource, permission or another user’s work?
• What confirms completion?
• How can a customer recover if synchronization fails?

This action-by-action inventory is a useful scoping document. “The app works offline” is too broad to estimate or test reliably.

Make saved and submitted mean different things

Use status labels that describe what has happened. “Saved on this device” means the local copy exists. “Waiting to upload” means another step remains. “Submitted” should mean the authoritative service has accepted the action according to the product’s rules.

Consider whether locally saved work survives closing and reopening the app. If it exists only in memory, describing it as saved would be misleading. Also decide what happens when the person signs out, changes accounts or removes the app. These are product decisions, not details to discover after a support complaint.

A reasonable interface can show the pending item, its latest state and a recovery action. Avoid keeping a spinner active indefinitely: the customer needs to know whether they can leave the screen and whether further action is required.

Worked example: a technician submits an inspection

This is a hypothetical workflow, not a claim about a specific portfolio implementation. A technician downloads an assigned inspection, completes a checklist in a basement and takes three photographs without a reliable connection.

The app stores the draft and attachments durably on the device. It shows that submission is pending. When connectivity returns, the app uploads the required files and requests final submission. The backend confirms that the inspection is still assigned to this person and that required information is present.

Suppose the backend accepts the submission but the response never reaches the phone. The app must check or retry the same operation in a way that does not create a second inspection. A timeout alone cannot tell the client whether the original operation succeeded.

Now suppose the job was cancelled while the technician was offline. The app should preserve the notes and explain that the server cannot accept the inspection in its current state. A blind retry loop cannot resolve a business-rule conflict.

These two cases require different recovery paths even though both initially look like “upload failed.”

Agree how conflicts are resolved

A conflict occurs when local changes and server changes cannot both be applied as originally intended. Examples include two people editing a report, a manager changing an assignment or a customer updating an address from another device.

For each editable field or action, choose a rule. Some independent changes can be merged. Others require checking the record version and asking a person to choose. Replacing the older value with the newest timestamp can be acceptable for some low-risk preferences, but it is a poor default for every business record.

Android’s offline architecture guidance discusses conflict resolution as part of synchronization design. Although its implementation examples target Android, the underlying need to choose a conflict policy applies to a Flutter product too. Android offline architecture

Document the rule in customer language. “A cancelled job cannot be submitted; the local report remains available for review” is a testable product policy. “Resolve conflicts automatically” leaves too much undefined.

Treat retries as a coordinated client-and-server feature

A queue needs durable operation identifiers, meaningful states and an agreed response to failures. It should distinguish a temporary network problem from expired authentication, rejected input and a permanently unavailable resource.

For an operation that could be duplicated, the backend needs a duplicate-prevention contract. Stripe’s idempotent request mechanism is one concrete example: requests can carry an idempotency key so retries can return a previously established result. Your own API needs its own documented semantics; adding a header to the app alone does not provide that behaviour. Stripe idempotent requests

My recommendation is to preserve an operation’s identity across retries and define how long the server remembers it. Also decide how the client retrieves the confirmed result after a restart. File uploads may need their own identities and cleanup policy if a report never reaches final submission.

Design for operating-system limits

Background synchronization is helpful when the platform allows it. It should not be the only way customers can complete an important pending action. Mobile systems can restrict background processing, and continuous work has battery costs. Flutter background synchronization considerations

Provide a reliable foreground path: show pending work when the app opens, attempt synchronization under suitable conditions and offer a clear retry or resolution action. A network-connection indicator alone is not proof that your API is reachable or that a request will succeed.

Test the interruptions customers actually encounter

An offline acceptance checklist should cover more than switching airplane mode on before opening the app:

• Connection drops during submission, after the server may have accepted it.
• The app closes and restarts with unsent changes.
• The session expires while actions wait in the queue.
• The same item changes on another device.
• A file upload succeeds but final submission fails.
• Local storage is insufficient for an attachment.
• The customer signs out with pending work.
• Connectivity returns, but the backend rejects the action.

For each case, verify both the final server data and the explanation shown to the customer. A clean interface cannot compensate for duplicated or silently lost work.

If your app needs reliable use in the field, bring the actions that must survive disconnection to a project discussion. Those rules will define the architecture and the estimate.

Give each pending operation a durable lifecycle

A useful queue design names the states the product can actually recover from. In the inspection example, I would distinguish a locally saved draft, an operation ready to send, an attempt in progress, an uncertain result, confirmed submission and a blocked operation that needs attention.

The transition into “ready to send” should preserve enough information to resume after the process stops. The transition into “confirmed” should depend on authoritative confirmation. If the process disappears during an attempt, reopening the app should not automatically assume either failure or success.

Record the logical operation identifier separately from individual attempts. A retry may need a new diagnostic request identifier while still referring to the same intended inspection submission. Define who owns those identifiers and how they are reconciled; do not assume a client-generated value alone enforces uniqueness on the backend.

Keep an explanation alongside blocked work. A cancelled assignment, expired permission and invalid attachment require different decisions. A customer should be able to see which item needs attention and what they can safely do next.

Include attachments and account changes in the product policy

Attachments add a second lifecycle. An uploaded photograph may exist even when the inspection has not been submitted. Decide whether a retry can reuse it, when an abandoned upload expires, and which service is responsible for cleanup. Test a partial set of uploaded files rather than treating all attachments as one atomic event.

Account switching needs an explicit boundary. Pending work belonging to one person must not appear in another person’s session or be submitted with the wrong identity. The product owner should decide whether sign-out offers a warning, preserves encrypted local drafts for the original account, or requires another approved handling path. The right policy depends on the sensitivity of the data and operational needs.

Removing the app can remove locally stored work. If the product promises durable business records, explain when those records reach the server and what the customer can recover. Avoid language that implies a device-only draft is already backed up.

Rehearse a recovery story with product and support

Walk through a technician returning after a shift with three pending inspections. One is accepted, one belongs to a cancelled job, and one has an incomplete attachment. Ask the reviewer to identify the status of each without reading engineering logs.

Then ask support to explain what happened using approved diagnostic references. Can they distinguish a slow upload from a rejected business operation? Can they help the technician preserve work while resolving the issue? If the only instruction is “delete and reinstall,” the recovery design needs more work.

Capture the agreed behaviour in the release checklist and maintenance handover. Offline support becomes maintainable when its decisions survive the original implementation team.

Sources

• Flutter: offline-first support
• Android Developers: offline-first architecture
• Stripe: idempotent requests

The workflow, status labels and acceptance checklist are editorial recommendations. The inspection scenario is hypothetical; exact storage, retry and conflict policies depend on the product.