Una web app guarda datos de usuario, catálogos offline y estado de borrador en localStorage e IndexedDB, tratando al navegador como base de datos de registro. Dentro de un WebView ese supuesto se rompe: el almacenamiento es best-effort, nunca garantizado. Bajo presión de almacenamiento el navegador purga un origen entero de una vez (LRU); Safari borra el almacenamiento escribible por script tras siete días sin interacción; las actualizaciones y reinstalaciones de la app vacían el directorio de datos del WebView; y el contenido incrustado en el WKWebView de otra app se limita a casi el 15 por ciento del disco total. Un runtime propio del host ofrece persistencia controlada — un almacén sincronizado con el servidor, migraciones versionadas y una garantía de durabilidad en la que la página puede confiar.
Presión de almacenamiento: la purga de todo o nada
Según la especificación de almacenamiento web, cuando un dispositivo se queda sin espacio el navegador aplica una política de menos usado recientemente (LRU) y borra todos los datos de un origen de una vez — IndexedDB y la Cache API desaparecen juntos, no clave por clave. Solo se omiten los orígenes con almacenamiento persistente vía navigator.storage.persist(), y esa concesión depende de señales de compromiso y a menudo es un false silencioso. Para un WebView dentro de la app es peor: las cifras medidas muestran que el contenido web incrustado en el WKWebView de otra app recibe solo cerca del 15 por ciento del disco total, frente a aproximadamente el 60 por ciento de una app de navegador autónoma. Una PWA que funciona en silencio en Safari se rompe dentro de la vista embebida.
El borrado silencioso de siete días y la trampa de memoria
Safari purga proactivamente el almacenamiento escribible por script — localStorage y sessionStorage incluidos — de cualquier sitio sin interacción del usuario en los últimos siete días de uso de Safari, salvo que esté instalado en la pantalla de inicio. Por separado, algunas apps contenedor de iOS dejan el almacén de datos del WKWebView en configuración no persistente (en memoria), así que el localStorage desaparece en cuanto el proceso termina o la app pasa a segundo plano. La escritura parece tener éxito durante la sesión y luego los datos simplemente no están. Los equipos híbridos descubren rutinariamente tokens y preferencias perdidos tras un cambio a segundo plano o una actualización.
Qué pierdes cuando el almacenamiento se evapora
- Catálogos offline desaparecen. Las listas de productos y artículos en caché se purgan bajo presión y la app cae en esperas.
- Estado de borrador perdido. Formularios a medias y ediciones no sincronizadas se van sin aviso.
- Cierre de sesión silencioso. Los tokens en localStorage se borran, forzando reautenticación en el peor momento.
- Migraciones rotas. Una actualización que vacía el directorio de datos o recrea el WebView puede dejar al usuario entre versiones de esquema.
- Sin contrato de durabilidad. localStorage es síncrono, con tope cercano a 5 MB por origen, y lanza QuotaExceededError — nunca fue base de datos de registro.
La solución del runtime
Un runtime propio del host deja de tratar al WebView como fuente de verdad. Ofrece un almacén sincronizado con el servidor por debajo de la página: el estado crítico se persiste de forma nativa (sobrevive actualizaciones, reinstalaciones y limpiezas del SO), se refleja en la página al cargar y se migra con versionado explícito cuando cambia el esquema. El H5 conserva la conocida API con forma de localStorage, pero el runtime garantiza la durabilidad que el WebView no puede.
| Dimensión | WebView | Runtime propio del host |
|---|---|---|
| Garantía de persistencia | Best-effort, ninguna | Duradera, nativa |
| Presión de almacenamiento | Purga de origen entero | Sincronizada con servidor, segura |
| Actualización / reinstalación | Vacía el dir. de datos | Sobrevive |
| Regla de 7 días iOS | Borra almacenamiento | Almacén nativo exento |
| Cuota dentro de la app | ~15% del disco | Controlada por el host |
| Seguridad de migración | Frágil | Versionada |
La API de almacenamiento de un navegador promete comodidad, no durabilidad. Un WebView estándar quita incluso esa comodidad en silencio. Un runtime convierte la Caja Amnésica en un almacén real — uno en el que la página puede confiar tras actualizaciones, reinstalaciones y días de disco lleno.
Fuentes
- MDN — Cuotas de almacenamiento y criterios de evicción — evicción LRU y la purga de todo o nada.
- web.dev — Almacenamiento para la web — almacenamiento persistente, cuotas y buenas prácticas.
- MDN — Window.localStorage — la API síncrona de 5 MB que nunca fue una base de datos.
- Apple — WKWebsiteDataStore — la decisión de almacén persistente vs no persistente en iOS.
- Android — Cambios de comportamiento en Android 9 (directorio de datos WebView por proceso) — por qué el almacenamiento se fragmenta y se borra entre procesos y reinstalaciones.
