Debug in-app pages (WebView / WKWebView)

Browser tabs are the easy case. The pages that actually break are the ones embedded in a hybrid app. WebDebugX lists those next to browser tabs and opens them in the same inspector — but the app has to opt in first.

Why an opt-in exists

A page is inspectable because its author enabled web debugging. That is a platform decision, not something WebDebugX can or should bypass. It is also why you cannot inspect somebody else’s production app — and why you can safely run this tool near production devices.

Android — WebView

Add this once, early in your app (an Application or the activity that hosts the WebView):

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
    WebView.setWebContentsDebuggingEnabled(true);
}

Kotlin:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
    WebView.setWebContentsDebuggingEnabled(true)
}

Rebuild and install that build on the device. Then follow Debug Android — the WebView pages now appear in the page list.

Gate it for release

Guard the call so it never ships enabled, for example with BuildConfig.DEBUG:

if (BuildConfig.DEBUG && Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
    WebView.setWebContentsDebuggingEnabled(true);
}

A release build with debugging on lets anyone with a cable read your app’s web layer.

Finding the process

Each WebView-hosting process exposes its own endpoint. When you are diagnosing by hand:

adb shell ps | grep webview          # processes hosting a WebView
adb shell pgrep -f com.example.app   # the PID of a specific app

WebDebugX enumerates these for you; the commands are only useful when confirming the device side is healthy.

iOS — WKWebView

Enable web inspection on the web view. On iOS 16.4 and later this is an explicit property:

if #available(iOS 16.4, *) {
    webView.isInspectable = true
}

Before iOS 16.4, a debug build of an app is inspectable without extra code; release builds are not.

Then follow Debug iOS. The app’s pages appear in the page list alongside Safari tabs.

Gate it for release

Wrap isInspectable in #if DEBUG so production builds do not ship it.

Checklist when the page still is not listed

1. Is the flag in the build actually on the device? Reinstall — an old build without the flag looks identical from the outside.
2. Is the WebView on screen? A page that has not been created yet exposes nothing.
3. Did you refresh? The flag is not retroactive: click Refresh in WebDebugX.
4. Right app? Some apps host several processes; the page belongs to whichever process created the WebView.
5. Cross-check the platform tooling. If it is invisible to chrome://inspect or to Safari’s Develop menu too, the flag is not taking effect and the problem is in the app.