The form is where the transaction happens, and it is the first place a WebView betrays you. The checkout, the sign-up, the search box — every screen that asks the user to type is a screen where the engine and the operating system disagree about the keyboard, the cursor, and the input method. The user feels it as lag, jumping fields, and text that will not land. They do not debug it. They abandon the cart.
The keyboard that does not resize
On iOS, a WKWebView does not behave like Safari when the soft keyboard appears. The window does not resize; window.innerHeight does not shrink; position: fixed bottom bars stay put and get covered by the keyboard. The fix is to wire up the Visual Viewport API by hand and offset your toolbar — a detail a merchant page written for the open web never does. Worse, when an input at the bottom of the page gains focus, WKWebView auto-scrolls it into view, but the scroll target is sometimes wrong: the field jumps off-screen or sits under the keyboard. And iOS forbids programmatic focus to stop pages from popping the keyboard unbidden, so any flow that wants to advance the cursor must wait for a user gesture. A form that works in desktop Chrome and Mobile Safari drifts the moment it is loaded in a WebView.
The IME that drops your characters
On Android, the input-method editor — the thing that turns pinyin or kana into Chinese, Japanese, or Korean characters — is where WebView forms quietly lose data. During composition, compositionend can land text a character or an entire paragraph short; the cursor freezes at the start until composition ends; a controlled input that writes the intermediate pinyin back into state corrupts the field, duplicates syllables, or enters a loop. A documented 2026 case showed Android WebView voice input with a newline in the composition dropping the first paragraph entirely — the text never reached the DOM. The same code in a browser tab works; in a WebView it does not, because the engine rebuilds block DOM during composition and the composing region is invalidated.
The password autofill that vanishes
Move a login page from Safari into a WKWebView and the password-manager prompt often disappears. The system AutoFill depends on two conditions: the WebView must use the default WKWebsiteDataStore, and the app must configure Associated Domains with webcredentials linking it to the site. Use a non-persistent data store for a privacy mode and AutoFill is blocked outright. And even when autofill works, the save-password dialog frequently never fires in WKWebView, so users can fill but never store — the opposite of the Safari experience. A traffic app whose login is a hosted page is asking users to type credentials by hand on every visit.
The runtime fix
A host-owned runtime does not ship the merchant's form and hope the engine and the OS agree. It supplies a first-party input layer: it owns the keyboard/visual-viewport handling so fixed bars never hide, it normalizes focus and scroll behavior across engines, it pre-handles IME composition so characters and cursors land correctly, and it provides a sanctioned, secure autofill path tied to the host's own credential store rather than begging each merchant page to wire up domains. The form becomes a surface the platform guarantees, not a gamble per page.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
| Keyboard vs layout | No resize; fixed bars hidden | Visual-viewport handled; bars stay visible |
| Focus scroll | Wrong target; field jumps away | Normalized across engines |
| IME composition | Drops text; cursor freezes | Pre-handled; characters land |
| Autofill | Vanishing; save dialog absent | First-party secure path |
| Who owns it | Merchant page, engine-dependent | Platform-guaranteed input layer |
The through-line of this series is control. A WebView lets a merchant's form onto your app but hands the keyboard, the cursor, and the input method to a negotiation between two layers that do not fully agree. A runtime lets you own the input. For a catalog of other people's checkout pages, that ownership is the difference between a completed purchase and an abandoned cart.
Sources
- WKWebView gotchas: keyboard does not resize window; focus scroll jumps — iOS WebView needs Visual Viewport API; auto-scroll can hide the field.
- iOS WKWebView autofill requires default data store + Associated Domains — non-persistent store blocks AutoFill; webcredentials linking needed.
- WKWebView password autofill: save dialog often never fires — autofill partial; password saving unsupported in WebView.
- Android WebView IME composition bugs: dropped text, frozen cursor — controlled input vs composition conflict; common on iOS WebView.
- Android WebView voice input drops first paragraph on newline in composition — text never reaches DOM when composition crosses block boundary.
