The web is a great place to ship a screen. It is a poor place to reach the device. A checkout or a content page lives happily inside a WebView; the moment a feature needs a real piece of hardware — a Bluetooth peripheral, an NFC tag, a notification that actually wakes the phone, a task that runs while the app is closed — the web platform runs out of room. That gap is the capability ceiling, and it is where H5 mini-programs quietly stop being able to compete with native.
The device the web can't fully see
Mobile operating systems expose a vast native surface: cameras, biometric sensors, Bluetooth, NFC, precise location, background execution, local notifications, system sharing, health and wallet frameworks. The web platform reaches only a slice of it, and even that slice is uneven. Web standards such as Web Bluetooth, Web NFC, WebUSB, WebHID and Web Serial are Chromium-only experiments — they do not exist in Safari or in most in-app WebViews. So the same H5 screen behaves differently depending on which engine happens to render it, and the «write once» promise breaks at exactly the moment a feature needs the device.
A capability map that follows the engine
The compatibility tables make the ceiling concrete. Web Bluetooth is fully supported in Chrome and Edge (including Chrome on Android) but has no support in Safari, in Safari on iOS, or in Android or iOS WebViews (MDN). Web NFC can read and write tags in Chrome on Android (89+) and Android WebView (89+) but is absent on every desktop browser and on Safari on iOS (MDN). Web Push is the cruelest case on Apple's platform: an Apple DTS engineer confirmed that «Web Push Notifications will not work in apps with a WKWebView.» On iOS, Web Push exists only for web apps the user has added to the Home Screen (iOS 16.4+), never for content rendered inside another app's WebView. A traffic app that embeds H5 for its merchants therefore cannot promise Bluetooth pairing, NFC tap, or reliable push to those merchants — not on iOS, and not consistently on Android.
The fragile workaround: a private bridge
The escape hatch teams reach for is a JavaScript bridge — a per-super-app, privately invented channel that lets H5 call into native code. It works, until it doesn't. Every host reinvents the wheel: a different API shape, a different permission story, a different security model, and a new surface for the injection and attack problems this series has already covered. Bridges are updated on the host's schedule, not the web's, so they drift from the documented web platform and from each other. The result is capability that exists, but is fragmented, ungoverned, and impossible to audit across the catalog of mini-programs a platform hosts.
The runtime fix
A host-owned runtime replaces the ad-hoc bridge with a standardized, reviewed capability API. Instead of each mini-program negotiating a private channel, the runtime exposes one consistent set of device capabilities — Bluetooth, NFC, push, background tasks, camera, biometrics, local notifications, system sharing — behind a single, versioned, permission-scoped interface that works the same on every platform the host supports. The host defines what a mini-program may request, the user grants it per capability, and the call goes through a path the platform can audit. Capability stops being a per-app science project and becomes a governed service.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
| Native reach | A slice; engine-dependent | One consistent capability API |
| Bluetooth / NFC | Chromium-only; absent in iOS WebView | Exposed uniformly where the device allows |
| Push on iOS | Not available inside a WKWebView | Native push through the host channel |
| Bridge model | Private, per-super-app, ungoverned | Standardized, reviewed, permission-scoped |
| Auditability | Near zero across the catalog | One audited path per capability |
The through-line of this series is control. A WebView lets you draw a screen but not reach the device behind it; a runtime lets you reach the device through a boundary you define. For a traffic app whose value is exactly the things a phone can do — pay, pair, tap, notify — that boundary is the product.
Sources
- MDN: Web Bluetooth API — support matrix: Chrome/Edge yes, Safari and iOS/Android WebViews no.
- MDN: Web NFC API — Chrome on Android and Android WebView only; no iOS Safari.
- Apple Developer Forums: Web Push not available in WKWebView — DTS confirmation that Web Push does not work inside a WKWebView.
- WebKit: iOS web push requires Add to Home Screen (iOS 16.4+) — push is gated to installed Home Screen web apps, not in-app WebViews.
- MDN/OpenPWA: Web NFC browser usage (~35% global, StatCounter 2026) — global usage context for Web NFC support.
