In a real browser, the password manager pops the saved credential the moment a login field appears. Inside a WebView that field stays empty. On iOS, a WKWebView does not surface the user's Safari / iCloud Keychain passwords for web content; on Android, WebView autofill is disabled by default and gated behind autofill hints, an activity context, and a system autofill service. A host-owned runtime bridges a native credential provider — one login field that fills everywhere.
iOS: no Keychain passwords for web content
Apple's Password AutoFill documentation explains how the system offers saved credentials through textContentType — but that applies to the app's own native UITextFields. For web content rendered inside a WKWebView, the system does not offer the user's Safari-saved passwords the way Safari does. The QuickType bar that appears in Safari for a saved login is not reliably available to an arbitrary embedded WebView; the page-level credential suggestions users expect simply don't show up. Third-party password managers that run as Safari extensions or credential-provider extensions are likewise not present inside the embedded page. The result: the user who has the password saved in Safari re-types it by hand, inside your app.
Android: autofill is off by default
Android's Autofill framework has supported WebView since Chrome 61, but it is conditional and fragile. The WebView must be created with an activity context, the fields must carry autofillHints (or importantForAutofill must be set correctly), and the device's system Autofill service must be enabled and not overridden by the app or ROM. Plenty of WebViews disable autofill outright, and third-party password-manager autofill inside WebView content is inconsistent at best. The same login that autofills flawlessly in Chrome can sit empty inside the embedded browser — and unlike Chrome, the page can't prompt the user to save or fill.
What breaks when autofill dies
- Every login is a manual retype. The password the user saved in their browser is unreachable from the WebView, on both platforms.
- Weaker, reused passwords follow. When filling is hard, users fall back to memorable or duplicated passwords — the opposite of what a finance app wants.
- One-time codes are harder too. Domain-bound SMS / TOTP autofill that Safari offers natively isn't reliably surfaced in the embedded page.
- Support and drop-off climb. A login that "just works" in the browser becomes a friction point in the app, and support tickets rise accordingly.
The runtime fix
A host-owned runtime bridges a native credential provider. The page marks a field with a standard autocomplete hint, and the host resolves it through the platform's credential provider — iOS ASPasswordCredentialIdentity / associated-domain QuickType, Android the Autofill framework and credential-provider extensions. Saved logins, generated passwords, and one-time codes are offered natively and consistently. One integration, every engine, one filled field.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
| iOS saved passwords | Not surfaced for web content | Native credential provider |
| Android autofill | Off by default, gated | Native Autofill + provider |
| Third-party managers | Absent in page | Bridged to host |
| One-time codes | Unreliable | Native domain-bound fill |
| Consistency | Per-engine | Uniform |
A native app offers the saved login on every device. A stock WebView offers it on almost none. A runtime gives the page one login field — and the user's own saved credential at the end of it.
Sources
- Apple Developer — Password AutoFill — system offers saved credentials via
textContentType; recommendsASWebAuthenticationSessionfor third-party login, which supports Password AutoFill. - Apple Developer — Enabling Password AutoFill on an HTML input element — "Make sure a web view or webpage provides the correct AutoFill suggestions"; web AutoFill depends on the container and associated domains.
- Breeze — Embedding Mobile App Guidelines — "Autofill — not supported on iOS WebViews, for security reasons. Android WebViews support it"; notes WKWebView/SFSafariViewController trade-offs.
- Android Developers — Autofill framework — WebView autofill since Chrome 61; requires
autofillHints/importantForAutofilland an enabled system Autofill service. - CodingTechRoom — Enable Autofill in WebView with activity context — WebView needs an activity context and
setAutofillHintsfor autofill; application context silently breaks it.
