What this prompt does
This prompt makes the AI a senior mobile engineer that implements an offline-first sync layer and returns working code, not pseudocode. You give it your [stack] and local store, the [data_type] to sync, the [conflict_policy], and the [api_style], and it returns a text architecture diagram followed by the core sync engine, the queue, and a sample screen wired to it as separate code blocks.
The six deliverables build the layer in dependency order: a local schema and read/write layer the UI talks to first (never the network), optimistic updates that apply locally then enqueue a sync operation, a durable sync queue that survives app restarts with ordering and idempotency keys, conflict resolution following your [conflict_policy] with a hook for manual merges, exponential backoff with jitter plus pause/resume on connectivity change, and a visible sync-state indicator with retry. The structure works because offline-first looks trivial in a demo then eats a week in reality - the queue, retries, and conflicts are all edge cases the prompt forces you to design before launch.
When to use it
- Your app must remain fully usable with no network and sync changes later.
- You want optimistic UI updates that feel instant and reconcile in the background.
- You need a sync queue that survives app restarts without losing or reordering operations.
- Two devices can edit the same record and you need a defined conflict policy.
- You want users to see sync state (synced, pending, error) and retry failed items.
Example output
You get a text architecture diagram of the layers, then three code blocks: the core sync engine handling reconciliation and backoff, the durable queue with ordering and idempotency keys, and a sample screen showing optimistic updates plus a sync-state indicator with synced, pending, and error states and a retry path.
Pro tips
- Nail
[conflict_policy]early; retrofitting conflict handling after launch usually means rewriting the sync engine. - Set
[data_type]to your real entities, since the local schema and merge logic differ for simple records versus nested or relational data. - Make sure the queue uses idempotency keys so a retried operation is not applied twice on the server.
- Match
[api_style]to your backend - if it exposes updated_at timestamps, the conflict resolution can lean on them. - Keep the local read/write layer strictly first; if the UI ever reads the network directly, your offline guarantees break.
- Add jitter to the backoff, not just exponential delay, so reconnecting clients do not stampede the server at once.
- Test the full restart path: kill the app with operations still queued, relaunch, and confirm they drain in order rather than vanishing.
- Expose the manual-merge hook even under last-write-wins, because the one conflict that loses real user data is the one you will wish you could resolve by hand.
