Today WebView Bridge
Native Reference

Overview

Non-normative guidance for host implementers on iOS, macOS, Android, Windows, and Linux.

These pages show one way to satisfy the Contract on each platform. They are non-normative: where they differ from the Contract, the Contract wins. Treat the code as a starting point, not a copy-paste drop-in.

A conforming host, on any platform, must:

  1. Expose the todayWebViewBridge channel as an object with a postMessage(message): Promise surface.
  2. Dispatch on the message type and implement track, headers, and refreshToken per Capabilities.
  3. Resolve undefined for any unknown type — never reject.
  4. Reject with a non-empty error string only where the Contract allows it (refreshToken).
  5. Coalesce concurrent refreshToken calls into a single real refresh.

The platform difference is entirely in how the promise-returning channel is constructed. Apple WebViews get it for free; Android and WebView2 wrap their transport in a thin shim; Electron exposes an isolated preload facade. Every path restores the same postMessage(message): Promise surface.

  • iOSWKScriptMessageHandlerWithReply.
  • macOS — an AppKit WKWebView handler or the Electron desktop preload facade.
  • AndroidWebViewCompat.addWebMessageListener or a @JavascriptInterface + callback shim.
  • Windows — WebView2 host object, chrome.webview.postMessage + request-id shim, or the Electron desktop preload facade.
  • Linux — Electron contextBridge + main-process IPC in the full desktop app shell.

Several platforms share a transport and cannot be told apart from the channel shape alone — iOS vs macOS both use WKWebView, while Android vs Linux vs Windows expose a global channel object. Each host MUST inject the platform tag when the channel shape is ambiguous.