How to Test WebView Integration in Mobile Apps

WebView is an embedded browser inside a native app. It is handy for displaying HTML content, third-party login, legal docs, or hybrid UI. It is also a frequent source of bugs — navigation, security, c

WebView is an embedded browser inside a native app. It is handy for displaying HTML content, third-party login, legal docs, or hybrid UI. It is also a frequent source of bugs — navigation, security, communication with native code, performance, accessibility — each with its own pitfalls. This guide covers the test matrix.

What to test

Navigation

1. URL loads within 3 seconds on 4G
2. Back navigation works (either native back or WebView history)
3. Forward navigation works (if exposed)
4. External links open in system browser, not in-WebView
5. Redirects handled correctly (including JavaScript redirects)
6. Page title propagates to app nav bar

Rendering

1. Content fits viewport, no horizontal scroll
2. Fonts render at system size
3. Images load
4. Videos play (especially inline, without fullscreen prompt)
5. Dark mode respected (via prefers-color-scheme)
6. Long content scrolls smoothly

JavaScript bridge

1. Native method exposure works (Android: @JavascriptInterface, iOS: WKScriptMessageHandler)
2. Bridge injection happens after DOMContentLoaded
3. Bridge methods callable from JS
4. JS returns handled in native
5. Bridge secured — origin whitelist enforced

Input

1. Text input fields receive focus
2. Keyboard appears on focus
3. Keyboard-avoidance layout adjusts
4. Autocomplete / autofill works
5. Copy / paste works
6. Select / share works

Performance

1. Cold WebView first paint under 1.5s
2. JavaScript-heavy pages do not freeze main thread
3. Memory usage reasonable (WebView can leak big)
4. Backgrounding WebView does not kill it

Error states

1. No network → clear error page, not browser default
2. Page load failure → retry option
3. SSL error → warning respected, not bypassed
4. 404 page friendly

Security

1. HTTPS enforced (no HTTP for sensitive content)
2. Mixed content blocked
3. JavaScript evaluation limited to trusted origins
4. File:// access disabled unless needed
5. Cookie scope limited to this app's WebView
6. No file system access to app's private storage
7. CORS restrictions enforced
8. Cross-origin iframe sandboxed

Android specifics

1. WebView.setWebContentsDebuggingEnabled(false) in release
2. Target SDK 30+ compliance
3. safeBrowsingEnabled on
4. setAllowUniversalAccessFromFileURLs(false) — default but verify
5. Autofill provider integration

iOS specifics

1. WKWebView not UIWebView (deprecated)
2. allowsContentJavaScript scope
3. WebKit process isolation (default yes)
4. ITP / tracker blocking per iOS defaults

Accessibility

1. Screen reader (TalkBack, VoiceOver) reads WebView content
2. Heading structure exposed
3. Form fields labeled
4. Focus moves logically via keyboard

Common production bugs

1. External links trap user in WebView — no way out without force-close
2. Cookies persist across sessions exposing PII
3. Bridge method callable from any origin — malicious site can invoke native functions
4. WebView memory leak on repeated open — app OOMs over session
5. Dark mode not propagated — WebView stays light on dark-theme app
6. File input not functional on Android — onShowFileChooser not implemented
7. Third-party cookies blocked in WKWebView — OAuth / embedded widgets break

How to test

Manual

• Load your content, try every link, fill forms, test both online and offline
• Use Chrome DevTools to remote-debug Android WebView (chrome://inspect)
• Use Safari Web Inspector to debug iOS WKWebView
• Test bridge calls from JS console

Automated

# Appium — switch context to WebView
contexts = driver.contexts
driver.switch_to.context("WEBVIEW_com.example.app")
# Now you can use standard web selectors
driver.find_element(By.ID, "login_btn").click()
driver.switch_to.context("NATIVE_APP")

How SUSA handles WebView

SUSA automatically detects WebView contexts and switches to drive them with web-like interactions (when WebView debugging is enabled). It also tests the native ↔ WebView boundary: transitions, back navigation, content rendering, and bridge calls via JS evaluation.

susatest-agent test hybridapp.apk --persona curious --steps 150

Security scanner checks for common WebView misconfigurations (allowFileAccess, JavaScript evaluation, origin restrictions).

Design patterns

Prefer native over WebView

Native screens are more accessible, perform better, and avoid WebView's entire bug class. Use WebView only for: dynamic content (legal, blog, help), third-party login, content that must match web exactly.

Communicate via typed messages

Do not expose broad @JavascriptInterface. Define a strict message schema; validate every message; reject anything not on the allowlist.

Clear WebView data on logout

Cookies, cache, local storage all persist by default. Clear them when user signs out.

WebView is useful but expensive. Budget the testing time accordingly.