What this prompt does
This prompt builds an offline-first React Native app for [app_purpose]. It implements a local database with [local_db], a sync queue for pending operations, a conflict-resolution strategy ([conflict_strategy]), background sync on a [sync_interval] cadence, network-status detection with UI indicators, optimistic UI updates, data migration between app versions, push notifications via [push_service], biometric auth, and deep linking with [link_scheme]. It uses [navigation] for routing and [state_management] for state, and asks for a sync-status dashboard, retry logic, and data-integrity verification tests.
The structure works because offline-first is mostly about reconciliation, not storage. The sync queue records local operations while disconnected, and the [conflict_strategy] decides what happens when two devices change the same record. Optimistic UI feels instant, but it only stays trustworthy when paired with a clear resolution rule and integrity checks — so the prompt treats the sync dashboard and verification tests as first-class features rather than afterthoughts.
When to use it
- You're building an app that must keep working with no connectivity, like field data collection.
- Users edit the same data on multiple devices and you need a defined conflict rule.
- You want optimistic updates without risking silent data divergence.
- You need background sync on a schedule plus clear online/offline UI indicators.
- You're adding biometric auth, push, or deep linking to an offline-capable app.
- You want a sync-status dashboard and integrity tests instead of hoping sync "just works."
Example output
Expect an architecture with a [local_db] schema, a sync-queue implementation that captures pending operations, conflict-resolution logic following your [conflict_strategy], background-sync wiring on the [sync_interval], network-detection hooks driving UI state, and integration of [push_service], biometrics, and [link_scheme] deep links. The sync-status dashboard and integrity-verification tests are included so you can see what's pending, failed, or reconciled at a glance.
Pro tips
- Choose
[local_db]for your access pattern — a reactive store like WatermelonDB shines for large datasets with live queries, while simpler stores suit small ones. - Be explicit about
[conflict_strategy]; last-write-wins is simple but lossy, so add a manual-review option for records where losing an edit is unacceptable. - Tune
[sync_interval]to battery and freshness needs — syncing every few minutes when online is reasonable, but back off when the app is idle. - Keep optimistic UI honest by reflecting failed syncs in the dashboard rather than letting the screen lie about saved state.
- Plan data migration between app versions early; an offline device may upgrade with unsynced data in an old schema, and that's exactly when migrations break.
- Treat the integrity-verification tests as release gates, since real devices disagree in ways simulators rarely reproduce.
