What this prompt does
This prompt implements offline-first synchronization for a mobile app that must work without connectivity, including the conflict handling that teams usually bolt on too late. It moves through six steps: designing the local schema with sync metadata, building a change-tracking layer, implementing the sync engine, adding conflict detection and resolution, handling edge cases, and building sync-status UI. Forcing the metadata and conflict strategy into the schema from day one is what prevents data corruption later, after the data has already diverged.
The variables shape the system. [local_database] and [entity_count] define the mirrored schema, [sync_strategy] and [api_endpoint] plus [batch_size] drive the sync engine, and [priority_entity] decides what syncs first. [conflict_count] and [merge_ui] configure resolution, [background_service] runs sync off the UI thread, [max_retries] bounds retries, and [analytics_tool] receives sync metrics. The hardest value to get right is the conflict default per entity, since automatic strategies can quietly lose data.
When to use it
- You are building an app that must remain fully usable without internet.
- You need a local schema that carries sync metadata from the start, not added later.
- You want a change-tracking layer that logs every local write to a sync queue.
- You need real conflict detection when the same record changes locally and remotely.
- You want the hard edge cases (app killed mid-sync, clock skew) handled deliberately.
- You need a sync-status UI so users can see and resolve pending changes.
Example output
Expect a [local_database] schema mirroring [entity_count] entities with sync_status, version, local_id, and server_id columns, plus a sync_queue table logging every change. The middle steps produce a repository layer that records writes, a sync engine implementing [sync_strategy] against [api_endpoint] with pagination beyond [batch_size], and [conflict_count] resolution strategies including a [merge_ui] manual merge. Edge-case handling with exponential backoff up to [max_retries] and a sync-status UI with synced, syncing, pending, and error indicators round it out. It blends schema, code, and UI specs, with the sync metadata columns treated as first-class parts of the data model rather than afterthoughts.
Pro tips
- Put sync metadata (
local_id,server_id,sync_status,version) into the schema for all[entity_count]entities up front; retrofitting it after corruption appears is painful. - Store both old and new values on updates so conflict detection by version number actually works.
- Pick
[sync_strategy]and[batch_size]to match your data volume; large change sets need pagination to avoid timeouts. - Choose a default among the
[conflict_count]strategies per entity type; last-write-wins is convenient but silently loses data in some cases. - Don't skip the edge-case step; app-killed-mid-sync and clock skew are exactly where offline sync breaks in production.
- Use server-assigned timestamps to neutralize client clock skew rather than trusting device time, which drifts between devices.
