WKWebView's `window` Is Just a Global Object — Here's How H5-to-Native Messaging Actually Works

Misunderstanding `window` leads to brittle bridge code and security gaps. Once an iOS developer sees that `window` is just the JS global and the bridge lives in a subtree underneath it, the entire WKWebView communication model becomes a straightforward message dispatch system rather than a black box.

Many iOS developers treat `window` as synonymous with JSBridge, but it's simply the web page's global runtime object. WebKit injects `window.webkit.messageHandlers` when Native registers a script message handler, and that subtree becomes the actual bridge entry point. H5 calls Native by posting a message through a named handler channel; Native calls back by evaluating a JavaScript string that invokes a function attached to `window`.

The communication is message-passing, not direct function invocation. H5 sends a structured message with an action identifier, and Native dispatches it inside `WKScriptMessageHandler`. The return path uses `evaluateJavaScript` to execute a pre-defined H5 function, completing the round trip. This pattern scales into full JSBridge protocols with module routing, callback IDs, and error codes — but the foundation stays the same two primitives.

Common misconceptions include thinking `window` is an iOS-injected object, that H5 directly calls Swift methods, or that Native callbacks are limited to plain strings. In practice, Native assembles arbitrary JavaScript and must handle escaping, injection risks, and serialization costs.