AsyncStorage with Auto Backup vs MMKV with self-managed keys when restored data must be verifiable
20K reputation · 18 Jun 2020, 00:39 UTC
I'm designing local persistence for a React Native app (0.73-era, Android and iOS) where a reinstall or device-to-device restore must never silently resurrect stale state. The data is user preferences plus a small offline cache, and after any restore the app needs to prove the recovered records are intact and current before trusting them.
The trade-off I can't resolve: AsyncStorage is convenient but is swept into Android Auto Backup and iOS container restores by default, so old values can reappear on a new device with no signal that they were restored rather than freshly written. MMKV (or Keychain-backed storage) gives me control over backup exclusion and encryption, but if the encryption key lives in the platform keystore, restored files may be undecryptable on a new device — which is arguably worse than stale data.
My current plan is to store a schema version, record count, and checksum alongside the data and validate on cold start, but that detects corruption, not provenance.
Which approach do you pick when restored data must be verifiable: backup-inclusive AsyncStorage with a provenance marker, or backup-excluded MMKV with re-sync on fresh installs? Is there any reliable cross-platform way to distinguish "restored from backup" from "fresh install" at first launch? And should restored auth tokens ever be trusted, or always re-validated?