The ‘Write Once, Run Anywhere’ Lie: Why HarmonyOS Just Broke Your Cross-Platform Strategy

You’ve probably noticed your CI/CD pipeline crying for mercy lately. We are living in a tri-OS world now—Android, iOS, and HarmonyOS. The promise of H5 hybrid development was supposed to be our savior. Write a webpage once, embed it everywhere, and call it a day. But you and I both know that’s a fantasy.

Let’s be brutally honest: H5 is the illusion of ‘write once, run anywhere.’ The native bridge is the brutal reality of ‘maintain three times.’

The H5 page can’t access the camera, microphone, or file system on its own. It needs a JSBridge—a双向通信桥梁—to talk to the native app. And when HarmonyOS entered the chat, it didn’t just add another platform to maintain. It completely broke the rules of how we build these bridges.

The API Betrayal: Why AI Can’t Save You

You might think, ‘I’ll just feed my Android JSBridge code into an AI and ask for a HarmonyOS port.’ Good luck with that. The system SDK changes aren’t just syntax swaps; they are fundamental architectural shifts.

Take URL interception. On Android, you override shouldOverrideUrlLoading in WebViewClient. On HarmonyOS? That method doesn’t exist. You’re forced to use the Web component’s onLoadIntercept interface. Injecting JavaScript? Android lets you use loadUrl('javascript:***'). HarmonyOS demands runJavaScriptExt.

Even object injection is hostile to what we’re used to. Android’s addJavascriptInterface is replaced by HarmonyOS’s registerJavaScriptProxy—and woe to you if you try to use javaScriptProxy directly, because it only fires once during initialization. You can’t inject multiple objects dynamically. The abstraction layer is leaking, and it’s leaking fast.

The Death of Inheritance

Here is where the real friction begins. In Android, if you want a custom WebView, you just extend the class. Object-oriented inheritance is your best friend.

HarmonyOS takes that friend out back and shoots it.

HarmonyOS didn’t just change the language; it killed the inheritance.

HarmonyOS UI is built on ArkTS, which relies on struct-based definitions. It does not support class inheritance in the way Java does. You cannot simply extend a Web component. Instead, you are forced into a composition-based architecture. You have to wrap the Web component inside a custom component, manage the WebviewController internally, and expose it via callbacks.

And don’t think the controller references match up. The WebviewController in your wrapper holds a different reference than the one in your parent component. You have to define custom action types just to bridge the gap.

Composition over inheritance isn’t just a design preference anymore; it’s the only way to survive the tri-OS apocalypse.

The Path to Unification

It feels like a nightmare, but this friction is actually the path forward. By accepting that HarmonyOS requires a composition-based JSBridge—utilizing registerJavaScriptProxy and onLoadIntercept—you can finally build a bridge that supports both legacy Android and HarmonyOS from the same H5 codebase.

The exhaustion of triplicated codebases ends when you stop fighting the structural constraints of ArkTS and start adapting the underlying APIs to fit them. You rewrite the native glue. You accept the paradigm shift. And finally, your H5 pages run across Android and HarmonyOS seamlessly.

The tri-OS world isn’t going away. Stop trying to port your old inheritance patterns, and start building the bridges that actually fit the new reality.