React Native MMKV: Fast Storage and How to Keep It Secure

React Native MMKV is the fastest key-value storage option for React Native — roughly 30x faster than AsyncStorage — but by default it stores data unencrypted, so security is a choice you have to make explicitly. MMKV is a memory-mapped key-value framework originally built by WeChat, and react-native-mmkv wraps it with direct JSI bindings so reads and writes are fully synchronous. That performance is the reason people reach for it, but the same on-device file it writes to is readable by anyone who can get at the app's sandbox on a rooted or jailbroken device.

This guide covers what react-native-mmkv does well, where its defaults leave you exposed, and how to configure it so the convenience does not turn into a data-leak finding.

Why teams pick MMKV in React Native

AsyncStorage is asynchronous, bridge-bound, and slow for frequent access. MMKV react native storage is different: it talks to a native C++ core through JSI, so set and get return immediately with no Promises and no bridge round-trip.

import { MMKV } from 'react-native-mmkv';

export const storage = new MMKV();

storage.set('user.theme', 'dark');
storage.set('user.onboarded', true);

const theme = storage.getString('user.theme');
const onboarded = storage.getBoolean('user.onboarded');

You get strings, booleans, numbers, and ArrayBuffers, all synchronously. The current major version (v4) is a Nitro Module and requires React Native 0.76 or higher, and it pulls the native MMKVCore from CocoaPods and Gradle rather than bundling it as source, which avoids duplicate-symbol headaches if your native code also uses MMKV.

The default is not encrypted

The single most important thing to understand about react-native-mmkv is that a plain new MMKV() instance writes to disk in the clear. On a compromised device — rooted Android or a jailbroken iPhone — those files are readable. If you have been dropping auth tokens, PII, or feature flags that reveal business logic into MMKV, that is a plaintext exposure waiting to be found in a mobile pen test.

Encryption is opt-in and takes one field:

import { MMKV } from 'react-native-mmkv';

export const secureStorage = new MMKV({
  id: 'secure-store',
  encryptionKey: getEncryptionKey(),
});

MMKV encrypts values with AES. That protects data at rest against casual file access, but it only moves the problem: now the safety of everything depends on where that encryptionKey lives.

Key management is the real work

A hardcoded string in your bundle is not a key, it is a comment. Anyone can pull it out of a decompiled APK or an IPA. The key must come from the platform's secure hardware-backed store:

• On iOS, store it in the Keychain.
• On Android, store it in the Keystore / EncryptedSharedPreferences.

A common pattern is to generate a random key on first launch, persist it in the platform secure store, and pass it into MMKV on every subsequent launch. Libraries like react-native-keychain handle the platform bridging. The rule of thumb: MMKV holds the encrypted data, the OS secure enclave holds the key, and the two are never in the same file.

What does not belong in MMKV at all

Even encrypted, MMKV is a convenience store, not a vault. Some things should never land there:

Short-lived, high-value secrets like session tokens are better kept in memory or the OS secure store directly. Long-lived credentials, private keys, and anything covered by a compliance boundary (health or payment data) deserve their own hardened handling. MMKV is ideal for preferences, cached non-sensitive responses, and UI state — the high-churn, low-sensitivity data where its speed pays off.

Supply-chain hygiene for a native dependency

Because react-native-mmkv ships a native module, an outdated version can carry native-layer bugs that a pure-JS package would not. Pin it, watch its releases, and treat a major bump (like the v4 Nitro migration) as a real upgrade with testing rather than a blind bump. Auditing your package.json and lockfile for known issues across every mobile dependency is exactly what an SCA tool such as Safeguard automates; our SCA product page explains how that dependency scanning works. For a broader take on locking down mobile builds, the Safeguard Academy has walkthroughs on secrets handling and dependency review.

A practical setup

Putting it together, a sensible pattern separates a fast non-sensitive store from an encrypted one:

import { MMKV } from 'react-native-mmkv';
import { getOrCreateKey } from './secureKey';

// Fast, non-sensitive: preferences, UI state, cache
export const appStorage = new MMKV({ id: 'app' });

// Encrypted: anything that would matter if leaked
export const secureStorage = new MMKV({
  id: 'secure',
  encryptionKey: getOrCreateKey(), // reads from Keychain / Keystore
});

This keeps the design honest: the fast path stays fast, and the sensitive path is encrypted with a key you never ship.

FAQ

Is react-native-mmkv encrypted by default?

No. A default new MMKV() stores data unencrypted. You must pass an encryptionKey to enable AES encryption, and you are responsible for storing that key in the platform secure store.

Can I store JWTs or auth tokens in MMKV?

You can, but keep them in an encrypted instance and prefer the OS secure store or in-memory storage for short-lived, high-value tokens. Plaintext MMKV is the wrong place for any credential.

What React Native version does MMKV v4 need?

react-native-mmkv v4 is a Nitro Module and requires React Native 0.76 or higher. If you are on an older RN version, stay on the v2/v3 line until you can upgrade.

How is MMKV faster than AsyncStorage?

MMKV uses memory-mapped files and direct JSI bindings to a native C++ core, so calls are synchronous and skip the React Native bridge. AsyncStorage is asynchronous and bridge-bound, which makes it slower for frequent reads and writes.