A web app caches user data, offline catalogs, and draft state in localStorage and IndexedDB, treating the browser as a database of record. Inside a WebView that assumption breaks: storage is best-effort, never guaranteed. On storage pressure the browser evicts an entire origin at once (LRU); Safari deletes script-writable storage after seven days without interaction; app updates and reinstalls wipe the WebView data directory; and content embedded in another app's WKWebView is capped at roughly 15 percent of total disk. A host-owned runtime provides controlled persistence — a server-synced store, versioned migrations, and a durability guarantee the page can actually rely on.
Storage pressure: the all-or-nothing purge
Per the web storage spec, when a device runs low on space the browser applies a Least Recently Used policy and deletes an entire origin's stored data at once — IndexedDB and the Cache API vanish together, not key by key. Only origins granted persistent storage via navigator.storage.persist() are skipped, and that grant is based on engagement signals and is frequently a silent false. For an in-app WebView the odds are worse: measured figures show web content embedded in another app's WKWebView is allocated only about 15 percent of total disk, versus roughly 60 percent for a standalone browser app. A PWA that quietly works in Safari breaks inside the embedded view.
The silent seven-day wipe and the memory trap
Safari proactively evicts script-writable storage — localStorage and sessionStorage included — for any site with no user interaction in the last seven days of Safari use, unless it is installed to the Home Screen. Separately, some iOS container apps leave WKWebView's data store in the non-persistent (in-memory) configuration, so localStorage is gone the moment the process exits or the app goes to the background. The write appears to succeed during the session, then the data is simply not there later. Hybrid teams routinely discover tokens and preferences missing after a background switch or an app update.
What you lose when storage evaporates
- Offline catalogs disappear. Cached product lists and articles are purged under pressure, and the app falls back to spinners.
- Draft state lost. Half-written forms and unsynced edits vanish with no warning.
- Silent logout. Tokens stored in localStorage are wiped, forcing re-authentication at the worst moment.
- Broken migrations. An app update that clears the data directory or recreates the WebView can strand the user between schema versions.
- No durability contract. localStorage is synchronous, capped near 5 MB per origin, and throws QuotaExceededError — it was never a database of record.
The runtime fix
A host-owned runtime stops treating the WebView as the source of truth. It provides a server-synced store below the page: critical state is persisted natively (surviving updates, reinstalls, and OS cleanup), mirrored into the page on load, and migrated with explicit versioning when the schema changes. The H5 keeps the familiar localStorage-shaped API, but the runtime guarantees durability the WebView cannot.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
| Persistence guarantee | Best-effort, none | Durable, native |
| Storage pressure | Whole-origin purge | Server-synced, safe |
| App update / reinstall | Wipes data dir | Survives |
| iOS 7-day rule | Deletes storage | Native store exempt |
| In-app quota | ~15% of disk | Host-controlled |
| Migration safety | Fragile | Versioned |
A browser storage API promises convenience, not durability. A stock WebView quietly takes even that convenience away. A runtime turns the Amnesia Box into a real store — one the page can trust across updates, reinstalls, and low-disk days.
Sources
- MDN — Storage quotas and eviction criteria — LRU eviction and the all-or-nothing purge.
- web.dev — Storage for the web — persistent storage, quota, and best practices.
- MDN — Window.localStorage — the 5 MB synchronous API that was never a database.
- Apple — WKWebsiteDataStore — the persistent vs non-persistent store decision on iOS.
- Android — Behavior changes in Android 9 (per-process WebView data directory) — why storage is fragmented and wiped across processes and reinstalls.
