Browser storage, SQLite, Keychain. One API.
Strata Storage keeps set() and get() the same across web, iOS and Android. You still verify each read path. See the round-trip.
Browser storage, SQLite, Keychain.
Strata Storage keeps set() and get() the same across web, iOS and Android. You still verify each read path. See the round-trip.
Three platforms, three storage layers
A cross-platform app can end up with browser storage, SQLite and the Keychain, each with its own setup and failure modes, so you test the read path on three platforms before you trust it. Then a bug arrives from the platform you tested last.
How do you use one storage API on web, iOS and Android?
Use storage.set() and storage.get() in each build. The calls keep the same shape; register and test native adapters on a device. Choose a specific adapter when the store matters.
What sits underneath the call?
The adapter reference lists 11 adapters behind one API. Each owns its platform-specific read and write; your code keeps the set()/get() call shape. Supply get<T>() with a type when you want a typed result. Native adapters still need Capacitor registration and device testing.
Where does a browser value go?
The default web instance registers localStorage, sessionStorage, indexedDB, cookies, Cache Storage and memory; register the URL adapter separately. It isn't durable storage. In query mode, values can reach the server in a request because they sit in the address; use hash mode for client-side URL state.
What changes on iOS and Android?
Register the Capacitor adapters, then use secure for Keychain on iOS or EncryptedSharedPreferences on Android. SQLite, preferences and filesystem adapters are available too. A browser test can't prove a native read. Verify those paths on a device.
Add only the safeguards you use
AES-GCM encryption, compression and expiry are opt-in. Encryption and compression use the async API; a synchronous call can't perform either operation. TTL can be absolute or sliding, with methods to inspect and clean up expired values.
Does Strata Storage add runtime dependencies?
No. The core package has zero runtime dependencies and needs no provider. React hooks, Vue composables, Angular integration and Firebase sync live behind optional sub-path imports, so you add a binding only where the app uses it.
What happens to older web keys?
Since 3.0, localStorage and sessionStorage keys use the strata: prefix. On a read miss, Strata can adopt a pre-3.0 unprefixed value that matches its storage envelope; it won't bulk-sweep unrelated keys or overwrite a prefixed value. Nothing moves in bulk. Apps with fixed physical key names can opt out.
Follow a specific path
After the first round-trip, use the quick start to configure your chosen store. The key-prefix guide covers older web keys; the native device-verification guide takes that same read path onto a phone. A browser round-trip can't verify the native read path.
Get the release notes
Once you've tested the read path, the release newsletter keeps package changes and migration steps in view. Subscribe if you want those by email; you can leave the list from an email when it stops being useful.
Support the work
Keeping that read path working across releases takes package and documentation work. Strata Storage is MIT-licensed; voluntary support backs that work without changing package access. The support page explains the choices.
Not the right tool when
If one web app only needs localStorage, use it directly. Strata Storage is client-side key-value storage, not a database shared by several users; it is ESM-only and needs Node 24.13 or later in the toolchain. Its integrity checksum catches accidental corruption, not deliberate tampering. Use encryption for that.
Start with one package
Install strata-storage, import storage, and run the first set()/get() round-trip in your app. Capacitor projects register native adapters and sync the plugin before testing on a device.
Open this page