Persisting key-value preferences across launches

WHAT THIS TESTS Whether you can match a storage mechanism to the data's size, sensitivity, and access pattern, rather than defaulting to one tool for everything.

A GOOD ANSWER COVERS For a simple, non-sensitive key-value pair like a theme preference, AsyncStorage is the conventional choice: a persistent, asynchronous, unencrypted store with getItem and setItem returning promises. You serialize non-string values with JSON.stringify and parse them back on read. A common modern alternative is react-native-mmkv, which is much faster and offers a synchronous API backed by memory-mapped files, handy when you want to read a preference before first paint. For sensitive values such as auth tokens you should use a secure store, Expo SecureStore or the underlying iOS Keychain and Android Keystore, because those are encrypted. A full database like SQLite or WatermelonDB is overkill for a single flag and is meant for relational or large datasets.

COMMON WRONG ANSWERS Storing tokens or passwords in AsyncStorage, which is plain text on disk. Treating AsyncStorage as synchronous and reading before the promise resolves. Saving an object without stringifying it. Pulling in SQLite to persist one boolean. Forgetting to handle the first-launch case where the key does not exist yet and getItem resolves to null.

LIKELY FOLLOW-UPS Why is AsyncStorage not secure, how does MMKV achieve synchronous reads, how would you cache and hydrate the preference into state on startup, and what are the size limits.

ONE CONCRETE EXAMPLE To persist a theme: await AsyncStorage.setItem('theme', 'dark') when the user toggles. On app start, const saved = await AsyncStorage.getItem('theme'); if saved is null you fall back to the system default, otherwise you initialize your theme provider with it. If you needed the value synchronously to avoid a flash of the wrong theme, you would switch to MMKV and read getString('theme') directly during render.