localStorage in in-app browsers

Treat every in-app browser session as disposable, because that is what it is.

6 August 2026 · PAD team

What is available

localStorage and sessionStorage both work inside a WebView. The catch is scope and lifetime: the storage belongs to the host app's data store and is commonly cleared when the browser closes or the app is killed.

What that breaks

• Multi-step forms that save progress between visits
• Quiz funnels that expect a returning visitor to resume
• Consent state, so the banner reappears every time
• Anything using a client-side identifier to stitch sessions

Designing around it

Keep state in the URL where it is small enough, and on the server where it is not. A quiz that encodes its answers in the address survives anything, including the visitor sharing the link halfway through.

If you must persist client side, treat it as a cache rather than a source of truth, and make every step recoverable from the URL alone.

Analytics implications

Client-side identifiers reset constantly, so in-app traffic inflates unique visitor counts and destroys returning-user metrics. If a large share of your traffic is social, the dashboard is measuring the browser rather than your audience.

The pragmatic answer

For anything that genuinely needs continuity, move the visitor into the real browser early. The same mechanism that rescues a store link carries a session into Safari where storage behaves normally.