offline-sync
Use when a screen must work without network or a mutation must survive a lost connection - local storage choice, the outbox pattern with idempotency keys, background replay, and how to test it with a
SKILL.mdcatalog/agents/mobile-developer/skills/offline-sync/SKILL.md
GitHubOffline and Sync
Overview
Treat "offline" as a normal state, not an error condition: a screen that only works with a live connection is a defect on mobile. The hard part isn't detecting offline — it's making a queued mutation replay exactly once and keeping the UI honest about what's actually saved.
Local store
Follow the repo's existing choice (drift/sqflite for Flutter, Room for Android, SwiftData/Core Data for iOS) — don't introduce a second local-storage mechanism alongside one that's already there.
Outbox pattern
- Queue mutations in a local outbox table when offline; replay on reconnect.
- Every queued mutation carries a client-generated idempotency key, sent with the eventual request, so a retried replay (after a crash mid-sync, or a flaky connection that "succeeded" without the ack arriving) is deduplicated server-side instead of double-applied.
- Connectivity plugins (
connectivity_plusand equivalents) report the state of the network interface, not whether the server is actually reachable — treat the server's response as the source of truth for whether a request succeeded, not the interface state alone.
Background replay
- Android:
WorkManager(native) or theworkmanagerplugin (Flutter) for replay that must survive the app being backgrounded or killed. - iOS:
BGTaskSchedulerfor background replay — register and schedule it, and test on-device since the simulator's background scheduling is unreliable.
UI honesty
Show sync status explicitly per item — pending / syncing / failed — never render an unsynced change as if it were already saved. A spinner that never resolves is worse than an honest "failed, tap to retry."
Conflicts
Pick one conflict rule per data type (last-write-wins, or an explicit user choice when both sides changed) and write it down in the task — don't leave it implicit in the code for the next person to infer.
Reads degrade gracefully
Cached data with a staleness indicator beats a spinner that never resolves — show what you have, mark it as possibly stale, and update when the network returns.
Testing
- Unit tests: a fake clock and a fake network/repository to drive queue → replay → ack deterministically, including the "replay happens twice" case to prove the idempotency key actually dedupes.
- On a local emulator:
adb shell cmd connectivity airplane-mode enable/disableto exercise a real reconnect, not just a mocked one.
Common Mistakes
- A screen that shows a blank/error state the instant the network drops, instead of cached data.
- A queued mutation with no idempotency key — a retried replay double-applies it.
- Trusting the connectivity plugin's "online" state as proof a request will succeed.
- A sync-status UI that doesn't distinguish
pendingfromfailed. - Only testing airplane-mode-on; never testing the reconnect/replay path.
Red Flags
- A mutation sent to the server with no client-generated key the server can dedupe on.
- "It works offline" verified only by reading the code, not by actually toggling airplane mode or a fake network.
- No written conflict rule for a data type that can be edited from two places.