How to Test WKWebView (Embedded WebViews) in iOS Apps

Short answer: there's no reliable online WebView tester for a webview inside your app, because the webview only exists in your running app. To test it, set webView.isInspectable = true in your debug builds. The default is false. Then inspect the web content from Safari's Develop menu on a Mac, with either a simulator or a cabled iPhone. Most webview bugs happen where native and web meet, so test that boundary: the JavaScript bridge, cookies and sign-in, navigation and the back button, links that should leave the app, and what happens when the network drops.

Checklist

• Web Inspector can attach (isInspectable = true in debug builds)
• Page loads, plus loading, error and offline states
• JavaScript ↔ native messages in both directions
• Cookies and session: logged in, logged out, expired token
• Back button and swipe-back vs canGoBack
• External links, tel: and mailto: links, and Universal Links leave or stay as designed
• File upload, camera and photo pickers inside the page (real camera on a real device)
• Rotation, Dynamic Type and keyboard covering form fields

How do I debug a WKWebView in the iOS Simulator?

1. In your app, set the property on each webview you want to inspect:

swift let webView = WKWebView(frame: .zero, configuration: WKWebViewConfiguration()) #if DEBUG webView.isInspectable = true #endif

2. Run the app on a simulator. Apple says Web Inspector is always turned on for simulators, and booted simulators appear in Safari's Develop menu (Apple: Inspecting iOS and iPadOS).
3. In Safari on your Mac, open Develop, choose the simulator, then choose your app's webview. Content is grouped by app.

On a real iPhone: turn on Settings > Apps > Safari > Advanced > Web Inspector, connect the iPhone to the Mac with a cable, and trust the Mac if asked. The device then appears in the Develop menu. After that, you can turn on Connect via Network from the device's submenu.

Why can't Safari Web Inspector see my webview?

• isInspectable defaults to false, and you have to set it on each WKWebView (Apple: isInspectable). Setting it back to false during a session closes Web Inspector.
• On a device, Web Inspector isn't turned on in Settings, or the Mac isn't trusted.
• The content is in an SFSafariViewController rather than a WKWebView, which is a different component (see below).
• The webview has been released, or you're looking under the wrong app in the Develop menu.

WKWebView, SFSafariViewController or ASWebAuthenticationSession: which are you testing?

Component	What it is	What you can test from your app
WKWebView	A webview inside your UI that your app controls	Everything: JS bridge, cookies, navigation delegate, layout
SFSafariViewController	Safari's own interface, presented modally	Presentation, dismissal and return to your app. Interactions with the page stay inside the view controller (Apple).
ASWebAuthenticationSession	A system browser sheet for OAuth sign-in	Redirect back to the app, cancel and errors

For OAuth sign-in, the native-app best practice in RFC 8252 says apps must not use embedded user-agents such as an in-app WKWebView. If your sign-in runs in a WKWebView, report it as a defect. See How to test OAuth sign-in on iOS.

How do you test a webview login?

Cookies and website data live in the webview's WKWebsiteDataStore. By default it saves data to disk, while nonPersistent() keeps data in memory only, like private browsing (Apple: WKWebsiteDataStore). Test cases:

1. A person signed in natively opens the webview. Are they signed in there too, if that's how it's designed?
2. A person signs out natively. Is the web session cleared as well?
3. The token or cookie expires while the webview is open. The page should handle it cleanly, without a blank page or redirect loop.
4. Kill and relaunch the app. The session should persist or clear according to the data store you chose.
5. Two accounts in a row on the same device. The second account must not see the first account's data.

What about the JavaScript bridge and navigation?

• Native → web: calls to evaluateJavaScript(_:completionHandler:) succeed and fail safely when the page isn't loaded yet.
• Web → native: each message type your page sends is handled. Unknown or malformed messages are rejected rather than crashing the app.
• Navigation: your WKNavigationDelegate lets in-app links load, sends external links to Safari or the right app, and handles errors such as no network, timeouts and SSL failures.
• Back: the native back button matches canGoBack / goBack(). It shouldn't leave the screen while there's web history, unless that's the design.
• Security: check that values from the web aren't trusted without validation, and that the page sets a Content Security Policy to limit XSS.

Can XCUITest interact with webview content?

Yes. In our experience, XCTest UI tests (Apple: XCTest) can query elements in a WKWebView through the accessibility tree, so good labels on the web side make those tests possible. Use Web Inspector for DOM-level checks, and keep a short real-device pass for anything that depends on hardware or the network.

Android counterpart: turn on WebView.setWebContentsDebuggingEnabled(true) in debug builds and inspect from chrome://inspect (Android: Debug WebViews with Chrome DevTools).

How does Mobot test embedded webviews?

Mobot runs your app, native screens and webviews alike, on real iPhones and Android phones tapped by physical robots. That includes sign-in handoffs, back navigation, links that leave the app, and pickers that use the device's real camera. Mobot AI and Mobot's team build your test cases from the flows that cross between native and web screens. Defect reports include device screenshots of each step.

FAQ

Is there an online WebView test tool for iOS apps? Not for a webview inside your app. An online tester only loads your web page, not your app's WKWebView with its cookies, JavaScript bridge and native screens. Inspect the real webview with Safari Web Inspector on a simulator or a connected iPhone instead.

How do I debug a WKWebView in the iOS Simulator? Set isInspectable = true on the webview, run the app on a simulator, and choose the simulator and your app's webview from Safari's Develop menu on your Mac. Web Inspector is always turned on for simulators.

Why can't Safari Web Inspector see my webview? isInspectable defaults to false and must be set on each WKWebView. On a device, Web Inspector also has to be turned on in Settings > Apps > Safari > Advanced, and the Mac must be trusted.

How do you test a webview login? Test native-to-web session sharing, sign-out clearing, token expiry while the page is open, relaunch persistence, and switching accounts on the same device.

Can XCUITest interact with webview content? Yes, in our experience, through the accessibility tree. Use Web Inspector for DOM-level debugging.