One interface, five shells

1. There are only two engines

The compatibility story is much better than "five platforms" suggests. WebKit powers WKWebView and WebKitGTK; Chromium powers WebView2 and Android's WebView. Both are modern, both run ES6+, and both run the Qbix JS runtime unchanged.

2. The U-side interface

Calling into a webview is asynchronous — the answer arrives later, from outside the process. That is exactly what a GPU readback is and what an HTTP response is, so it needs no new concurrency concept: it is one more thing the fiber scheduler waits on.

d WebView
	title: S
	width: I
	height: I

f open(cfg: WebView +R) -> WebView +R ! NetworkError
f load(view: WebView +R, page: HTML) -> N +A
f eval(view: WebView +R, script: JS) -> S +A
f on(view: WebView +R, channel: S) -> [Message] +R

Note eval takes a JS value, not a string — so a value crossing into the page has already been encoded, and the </script> and U+2028 hazards are handled before it leaves U.

3. The bridge — three variants, not five

Each host exposes a different JS→native channel. U emits a small shim that normalises them, so U-side code sees one interface. The WebKit family shares an identical JS call, which is why there are three variants rather than five.

Native→JS is uniform in shape everywhere — "evaluate this script, deliver the result later" — which is why it maps onto +A without special cases: webkit_web_view_evaluate_javascript, evaluateJavaScript:completionHandler:, ExecuteScript, evaluateJavascript.

window.U = window.U || {};
U.post = (window.webkit && webkit.messageHandlers && webkit.messageHandlers.u)
  ? function (m) { webkit.messageHandlers.u.postMessage(m); }
  : (window.chrome && chrome.webview)
  ? function (m) { chrome.webview.postMessage(m); }
  : function (m) { window.u.post(JSON.stringify(m)); };

Messages are JSON both ways. That is not laziness: Android's addJavascriptInterface only passes primitives and strings reliably, so JSON is the honest lowest common denominator across all four.

4. Every host needs UI-thread marshalling

This is the one place the concurrency model has to grow to meet the GUI, and it is worth knowing before starting rather than discovering in the Android shell.

So the scheduler needs a post-to-UI-thread queue alongside the epoll reactor. Fibers keep running on the reactor; anything touching the view is handed to the UI queue and its result comes back as a +A completion.

5. Serving the assets

Markup, CSS and JS have to reach the view. file:// is simplest and wrong: it carries origin restrictions that break fetch and XMLHttpRequest, which is exactly what a Qbix front end uses. The answer is a custom scheme handler, which all four hosts support.

Assets are then served from memory under a real origin (say app://local/), so relative URLs, fetch and cookies all behave as they would on a server.

6. Qbix compatibility — the front end does not change

Both engines are modern, so the Qbix JS runtime loads and runs unmodified. Nothing about tools, templates or events needs a native variant.

That last row is the interesting one. A Qbix tool normally reaches the server over HTTP. Inside a U shell the same call can be routed to the bridge instead — the request never leaves the process, U handles it directly, and the tool's code does not change. Same front end, no network, no server to run locally.

Q.Tool.define("MyPlugin/thing", function (options) {
    var tool = this;
    Q.req("MyPlugin/data", ["items"], function (err, data) {
        tool.state.items = data.slots.items;   // served by U over the bridge
        tool.stateChanged("items");
    });
});

7. Per-target notes

• iOS — the cheapest mobile target. U compiles to C and Objective-C is a strict superset of C, so the shim is thin. WKWebView is App Store-approved; UIWebView is banned. Local content needs loadFileURL:allowingReadAccessToURL: or the scheme handler.
• Android — the only target where the shell is a subproject. The NDK gives you C, but the WebView lives in Java, so everything crosses JNI; addJavascriptInterface methods need the @JavascriptInterface annotation, only primitives and strings cross reliably, and every view call must be on the UI thread. evaluateJavascript needs API 19+.
• Windows. WebView2 initialises asynchronously through COM and requires the Evergreen runtime to be present on the machine — the one target with an external dependency the user can be missing.
• Linux. The easiest binding: a plain C API over GTK. Needs gtk3/gtk4 and webkit2gtk at build time.
• macOS. Same WKWebView code as iOS, plus a real window and menu bar. Sandboxing and notarisation apply for distribution.

8. What this is not good for

• Games and high-framerate UI — use the GPU path instead
• Deep OS integration (menus, tray, native file dialogs) — needs per-platform escapes
• Very constrained memory
• Windows requires the WebView2 runtime installed

9. Build order

1. Linux (WebKitGTK) — plain C, fastest to a working window, and it proves the bridge and the UI queue
2. macOS (WKWebView) — the Objective-C shim, reused verbatim by iOS
3. iOS — packaging and the scheme handler; the shim already exists
4. Windows (WebView2) — COM plumbing
5. Android — JNI and the Java UI thread; last because it is a subproject, not a shim

The UI-thread queue lands with step 1 and is shared by all of them.