Expo Offline Progress: Separate Reference Data from User Records

Offline progress tracking works best when the app separates reference content from the user's own records. Replacing a bundled catalogue should not erase completed tasks, and switching profiles should not merge unrelated progress.

The Expo collection includes Stardew Valley Tracker, which describes offline use and separate save-file tracking, and Pokopedia, which describes bundled reference content and progress features. These are listing descriptions, not an audit of either application's storage implementation.

Give reference items stable identities

A reference item needs an identity that survives changes to its display name or description. User progress should point to that identity rather than the position of an item in a list.

When new content arrives, distinguish a renamed item from a genuinely new one. If an item is removed, decide how its historical progress remains understandable.

Avoid resetting a whole progress table simply because the reference dataset has a new version. That shortcut destroys the separation the user depends on.

Scope progress to the right profile

Define whether a progress record belongs to a device, an account, a workspace or a particular save file. A person may legitimately have several independent profiles.

Test creating two synthetic profiles and completing different items in each. Switch repeatedly, restart the app and verify that the visible state remains associated with the correct profile.

The interface should make the active profile recognizable before a destructive reset or bulk update.

Choose persistence for the promise

Expo's SQLite documentation describes local database access with persistence across application restarts. That is one implementation option; a declared Expo association does not prove an app uses SQLite.

Persistence across restart is also narrower than backup, cross-device sync or survival after uninstall. Explain those capabilities separately. A user should not have to discover the distinction after replacing a phone.

If export is supported, verify that it contains the records needed to recreate useful progress, not only a summary count.

Handle offline changes before adding sync

Define what happens when the same item changes on two devices or in two sessions. “Last write wins” may be acceptable for some preferences and unsuitable for records that need to preserve both contributions.

Keep a pending local change distinct from a confirmed synchronized change. If sync is optional, the local workflow should remain understandable when no account is connected.

Use synthetic conflicts to test the documented rule. Do not judge sync correctness merely by whether a spinner disappears.

Migrate existing records deliberately

Before a data-format change, create a fixture representing an older app with real-shaped progress. Apply the migration, verify record counts and inspect meaningful examples.

Keep the migration compatible with the release's recovery strategy. If the previous application cannot read the new format, a simple code rollback may not restore a usable experience.

The Expo runtime compatibility guide covers the other half of that release decision. Native compatibility protects execution; data compatibility protects the work people have already done.

Finish the review by documenting the supported offline task, storage scope and recovery options. Those promises make an offline feature useful well beyond the first successful launch.