Fragmented native channels
Android WebMessagePort, iOS WKScriptMessageHandler, Flutter JS channels, HarmonyOS ArkWeb — every platform speaks a different dialect of JS-Native messaging.
Multi-platform JS-Native bridge
One message protocol, one session model, and one set of WebAssets — running on Android, iOS, Flutter and HarmonyOS. Not a shared runtime: a shared contract.
Android WebMessagePort, iOS WKScriptMessageHandler, Flutter JS channels, HarmonyOS ArkWeb — every platform speaks a different dialect of JS-Native messaging.
Ad-hoc bridges lack a handshake, session lifecycle and cancellation semantics — every H5 page reinvents its own transport.
Origin checks, method whitelists and session validation end up duplicated and inconsistent across platforms and pages.
Without a common contract, each platform re-implements the bridge — and each drifted implementation raises integration costs.
01
A single message envelope — request / response / event — with handshake, session, timeout and scope cancellation defined once, in the spec.
02
A fixed evaluation order: shape → handshake gate → origin → method gate → session → host policies. Hosts extend, never override.
03
One jsbridge-sdk.js bundle runs identically in all four native shells. One source of truth, synced to every platform.
The goal is cross-platform protocol consistency — not a shared runtime.
Unidirectional dependencies: JsBridge → CoreBridge → api. CoreBridge has zero security dependencies; security has zero core dependencies.
Java 8 · gradle
Reference implementation. js-bridge-core + WebView transport adapter.
Read integration guide →Swift 6 · SPM
Swift Package with Bridge core plus a WKWebView transport in BridgeSystem.
Read integration guide →Dart 3 · pub
Core package plus host-app example. Transport injected via bindTransport().
Read integration guide →ArkTS · HAR
Stage-model HAR core with the same envelope, handshake and policy chain.
Read integration guide →