En un navegador real, el gestor de contraseñas muestra la credencial guardada en cuanto aparece el campo de login. Dentro de un WebView ese campo se queda vacío. En iOS, un WKWebView no muestra las contraseñas que el usuario guardó en el Keychain de Safari para contenido web; en Android, el autocompletado del WebView está desactivado por defecto y bloqueado por sugerencias de autocompletado, un contexto de actividad y un servicio del sistema. Un runtime propio del host conecta un proveedor de credenciales nativo: un campo de login que se rellena en todas partes.
iOS: sin contraseñas del Keychain para contenido web
La documentación de Password AutoFill de Apple explica cómo el sistema ofrece credenciales guardadas mediante textContentType, pero eso se aplica a los propios UITextField nativos de la app. Para el contenido web renderizado dentro de un WKWebView, el sistema no ofrece las contraseñas que el usuario guardó en Safari como lo hace Safari. La barra QuickType que aparece en Safari para un login guardado no está disponible de forma fiable en un WKWebView embebido cualquiera; las sugerencias de credenciales a nivel de página que el usuario espera simplemente no aparecen. Los gestores de contraseñas de terceros que funcionan como extensiones de Safari o de proveedor de credenciales tampoco están presentes dentro de la página embebida. El resultado: el usuario que tiene la contraseña guardada en Safari la vuelve a escribir a mano, dentro de tu app.
Android: el autocompletado está desactivado por defecto
El framework Autofill de Android admite WebView desde Chrome 61, pero es condicional y frágil. El WebView debe crearse con un contexto de actividad, los campos deben llevar autofillHints (o importantForAutofill debe configurarse correctamente) y el servicio del sistema Autofill del dispositivo debe estar activado y no anulado por la app o la ROM. Muchos WebViews desactivan el autocompletado por completo, y el autocompletado de gestores de contraseñas de terceros dentro del contenido del WebView es, en el mejor de los casos, inconsistente. El mismo login que se autocompleta perfectamente en Chrome puede quedar vacío dentro del navegador embebido, y, a diferencia de Chrome, la página no puede pedir al usuario que guarde o rellene.
Qué se rompe cuando el autocompletado muere
- Cada login es un reescritura manual. La contraseña que el usuario guardó en su navegador es inalcanzable desde el WebView, en ambas plataformas.
- Aparecen contraseñas más débiles y reutilizadas. Cuando rellenar es difícil, los usuarios recurren a contraseñas memorables o duplicadas: lo opuesto a lo que quiere una app financiera.
- Los códigos de un solo uso también se complican. El autocompletado de SMS / TOTP vinculado al dominio que Safari ofrece de forma nativa no se muestra de forma fiable en la página embebida.
- Suben el soporte y la desertización. Un login que «simplemente funciona» en el navegador se convierte en un punto de fricción en la app, y los tickets de soporte aumentan en consecuencia.
La solución del runtime
Un runtime propio del host conecta un proveedor de credenciales nativo. La página marca un campo con una sugerencia de autocompletado estándar, y el host lo resuelve mediante el proveedor de credenciales de la plataforma: ASPasswordCredentialIdentity / QuickType de dominio asociado en iOS, el framework Autofill y las extensiones de proveedor de credenciales en Android. Los logins guardados, las contraseñas generadas y los códigos de un solo uso se ofrecen de forma nativa y coherente. Una integración, cada motor, un campo relleno.
| Dimensión | WebView | Runtime propio del host |
|---|---|---|
| Contraseñas guardadas iOS | No se muestran para web | Proveedor de credenciales nativo |
| Autocompletado Android | Desactivado por defecto, bloqueado | Autofill nativo + proveedor |
| Gestores de terceros | Ausentes en la página | Conectados al host |
| Códigos de un solo uso | Poco fiable | Relleno nativo vinculado al dominio |
| Consistencia | Según el motor | Uniforme |
Una app nativa ofrece el login guardado en todos los dispositivos. Un WebView estándar lo ofrece en casi ninguno. Un runtime da a la página un campo de login —y la credencial guardada del propio usuario al final.
Fuentes
- Apple Developer — Password AutoFill — el sistema ofrece credenciales guardadas vía
textContentType; recomiendaASWebAuthenticationSessionpara login de terceros, que admite Password AutoFill. - Apple Developer — Habilitar Password AutoFill en un elemento de entrada HTML — «asegúrate de que una vista web o página web proporcione las sugerencias de autocompletado correctas»; el autocompletado web depende del contenedor y los dominios asociados.
- Breeze — Guía de apps móviles embebidas — «Autocompletado: no admitido en WebViews de iOS, por razones de seguridad. Los WebViews de Android sí lo admiten»; describe los compromisos de WKWebView/SFSafariViewController.
- Android Developers — Framework Autofill — WebView admite Autofill desde Chrome 61; requiere
autofillHints/importantForAutofilly un servicio del sistema Autofill activado. - CodingTechRoom — Habilitar Autofill en WebView con contexto de actividad — WebView necesita contexto de actividad y
setAutofillHints; el contexto de aplicación lo rompe en silencio.
