session.storage is a phone-local key-value store. It’s scoped to the user and
your miniapp, so your keys never collide with another miniapp’s, and the data
survives restarts. Keys and values are both strings.
Reading and writing
Bulk operations
For hydrating state on startup or saving several keys at once:Keep the total stored payload small (think under ~1 MB).
getAll() pulls
everything across the bridge at once, and a large namespace will stall the
background context while it resolves. For images, audio, or files, use
session.blob instead.Storing objects
Values are strings, so serialize structured data yourself:What the phone keeps
Your miniapp’s screen is a web page, and on iOS the system browser engine may delete a web page’s saved data when it hasn’t been interacted with for a while. The Mentra App protects the parts below, so they last like a normal app’s data.
How the screen’s
localStorage copy works:
- The 5 MB cap counts every key and value at two bytes per character, the way browsers count their own quota. A write that would go over it still works in the page, but isn’t kept, so that key may be gone after iOS clears the page’s data.
- Write with
setItem,removeItemandclear. Those reach the copy right away. A value set another way (localStorage.x = "1") is picked up when the screen closes or next opens. A key deleted another way (delete localStorage.x) isn’t seen, so it can come back. - It follows your
session.storage. It belongs to the signed-in account (and workspace, for miniapps a workspace installs), so another account on the same phone starts with its own. Signing out clears it. A development build keeps its own copy, apart from the installed miniapp’s.
session.storage or session.blob: they
are available to your background code too, and work while the screen is
closed.
