Crees que un usuario con sesión iniciada es un usuario con sesión iniciada. Luego toca una pantalla WebView y se le pide iniciar sesión otra vez. O llena un carrito dentro de WebView, vuelve a la carcasa nativa y el carrito ha desaparecido. La frontera entre tu código nativo y el documento remoto no solo ralentiza las cosas — elimina silenciosamente identidad y estado.
La frontera que olvida
Un WebView almacena sus cookies y almacenamiento local en el almacén de datos privado de la app huésped, no en el del navegador del sistema. Un navegador externo no puede leer ese almacén privado, así que abrir un enlace significa un inicio de sesión nuevo. Incluso dentro de la app, un navegador in-app se comporta como una ventana de incógnito nueva que lo olvida todo al cerrarse. Un usuario que inició sesión vía Safari y llega a tu página desde Instagram aparece como visitante anónimo, y la sesión creada allí no regresa. Las consecuencias documentadas son contundentes: las paredes de login convierten mucho peor en tráfico in-app, los contenidos del carrito y las preferencias no se trasladan, y el analytics cuenta a una persona como varias.
Si llevas el WebView a su propio proceso — una corrección común de estabilidad — el problema se endurece. Las cookies, el estado de login y el almacenamiento local quedan en el proceso WebView; la carcasa nativa debe sincronizarlos explícitamente o simplemente no se comparten.
El colapso de las cookies de terceros lo empeoró
La muerte lenta del rastreo entre sitios elevó la apuesta. Safari comenzó a bloquear cookies de terceros por defecto en 2017 con Intelligent Tracking Prevention; Firefox siguió en 2019; Chrome anunció una eliminación en 2020, luego retrocedió y cerró la mayoría de las APIs de Privacy Sandbox para octubre de 2025. Para 2025, aproximadamente el 47% del tráfico web ya no usaba cookies. Para una app que depende de WebView, eso significa que los frágiles puentes que antes cosían la identidad entre contextos se están quitando de debajo, y el analytics que dependía de ellos ahora reporta visitantes nuevos fantasma.
Una superficie de fraude y riesgo que no contrataste
Los navegadores embebidos que aíslan cookies y almacenamiento local hacen más que molestar a los usuarios. El análisis de Fingerprint muestra que fragmentan sesiones y debilitan la atribución, y crean aperturas para el fraude: los atacantes pueden borrar estado, cambiar de contexto o usar dispositivos manipulados mientras avanzan por flujos de onboarding, checkout o promociones. La pregunta de gobernanza deja de ser comodidad del navegador y se convierte en si los controles de identidad y riesgo pueden sobrevivir al cambio de contexto dentro de tu propia app. La recomendación de ese análisis es el instinto correcto: persiste el vínculo entre usuario, dispositivo y journey en un sistema backend gobernado, no en cookies o almacenamiento local que una frontera WebView puede borrar.
Lo que cambia un runtime de primera parte
Un runtime propio del host ejecuta el mini-programa como un componente firmado y de primera parte, con identidad y estado gestionados por el host en lugar de abandonarse en la frontera del documento. La carcasa nativa y el runtime comparten un ancla de identidad gobernada, así que un login hecho una vez se honra en todas partes, y un carrito o progreso sobrevive al movimiento entre pantallas. La continuidad de identidad deja de ser una apuesta entre contextos y se convierte en una propiedad de la plataforma que controlas.
| Cruce de estado | WebView por defecto | Runtime propio del host |
|---|---|---|
| Login nativo → WebView | Re-preguntado; almacén privado no compartido | Un ancla de identidad gobernada |
| Carrito WebView → nativo | Perdido en la frontera | Sobrevive entre pantallas |
| Identidad entre contextos | Fragmentada, brecha sin cookies | Persistida en backend, no en cookies |
| Resiliencia al fraude | Borrado de estado fácil, ancla débil | Vínculo de identidad duradero, consciente del riesgo |
