Is There a “Write Once, Run Everywhere” Solution for Android, iOS, and Harmony Next?

In today’s mobile landscape, small teams often find themselves spread thin across multiple platforms. Android and iOS have matured ecosystems with robust tooling, but Harmony Next—Huawei’s fledgling multi‑device OS—adds fresh complexity. This case study examines a real-world V2EX post by a two‑person team who needed to ship four cross‑platform apps simultaneously on Android, iOS, and Harmony Next. We’ll translate their experiences and community feedback into an actionable English blog: no extra assumptions, just the raw lessons from the source.

1. Background and Core Challenges

A team of two developers aimed to build four mobile apps covering three platforms:

  • ◉
    Android (Java/Kotlin)
  • ◉
    iOS (Swift/Objective‑C)
  • ◉
    Harmony Next (OpenHarmony-based)

Their dream: one codebase that targets all three platforms, minimizing the notorious “bridge code” and platform‑specific bugs. They outlined:

  • ◉
    Goal: Single source, three outputs; Harmony Next compatibility is non‑negotiable.
  • ◉
    Ideal: Mature ecosystem, comprehensive docs, abundant plugins (akin to Flutter’s Pub).
  • ◉
    Fallback: If no perfect solution exists, at least an ArkUI‑X demo showing basic system calls—contacts, network, and local storage.

2. Whirlwind Tour of Cross‑Platform Options

Below is a concise comparison of the main contenders, distilled from hands‑on trials and heated forum debates:

Framework Strengths Show‑Stopping Drawbacks
React Native Massive community; rich Android/iOS plugin ecosystem No official Harmony Next support; community forks feel shaky
UniApp / UTS Lightweight JS/UTS syntax; compiles to native quickly One code‐to‑rule‑them‑all brings platform quirks; Harmony Next compatibility unclear
Flutter Near‑native performance; robust Android/iOS/Web support Harmony Next relies on community bridges (e.g., harmony_next_bridge), no official maintenance
Tencent Kuikly More complete docs than Huawei; official examples available Non‑official plugin map; plugin marketplace barren; last update in October last year
Huawei ArkUI‑X ArkTS syntax resembles TypeScript; theoretically “three‑way” Ecosystem collapse—lack of plugins, dead docs, cryptic tooling, AI helpers clueless about ArkUI‑X

*(Source: forum table) *

3. ArkUI‑X’s Eight “Showstoppers”

Opting for ArkUI‑X as the “official three‑in‑one” path led to the following major pain points:

  1. Plugin Desert
    No centralized plugin registry (like pub.dev or npm). Even reading the contacts requires hand‑scribing a JSBridge.

  2. Ghost Town Community
    Forum posts get thousands of views but zero replies; GitCode Issue queues gather dust; automated support bots do nothing.

  3. Documentation Abyss
    All docs are scattered in GitCode repos—no official website. TS extensions even stripped out any and unknown, confusing AI code assistants.

  4. Version Schism
    ArkUI‑X (cross‑platform) vs. ArkUI (native Harmony)—two incompatible codebases. You cannot share components without runtime errors.

  5. Demo Scarcity
    Official examples are mere UI skeletons (buttons, lists). No demos for network requests, SQLite storage, or hardware APIs.

  6. AI Code Fiction
    Major LLMs (GPT, Claude, Gemini) lack ArkUI‑X knowledge, generating code that references nonexistent APIs or fails to compile.

  7. Toolchain Black Magic
    Environment errors like toolchains:-1 pop up. SDK downloads crawl at snail speed; domestic mirrors frequently time out.

  8. Maintenance Doubts
    Six months without updates, half‑year‑old unanswered issues—makes you wonder if anyone is actually using it.

*(Details: ArkUI‑X eight sins) *

4. The Three Core Questions

From this ordeal emerged three burning questions:

  1. Does a truly mature, Harmony Next‑capable “one‑code‑for‑three” solution exist?
  2. If tied to ArkUI‑X, are there reliable community plugins or minimal demos for system calls?
  3. Should they abandon “write once” in favor of three native UIs + shared logic (e.g., Kotlin Multiplatform)?

5. Community Recommendations: Pros, Cons, and Realities

V2EX members weighed in with pragmatic advice. We’ve consolidated their top suggestions.

5.1 When High‑Fidelity Interaction Matters → Flutter

“

“Flutter feels closest to native performance, and its ecosystem is rock‑solid.” — justsoup

  • ◉

    Strengths:

    • ◉
      Flutter’s Skia‑based engine yields smooth animations and complex gestures.
    • ◉
      Thousands of mature plugins for Android/iOS; strong community support.
  • ◉

    Caveat:

    • ◉
      Harmony Next support via harmony_next_bridge is community‑driven—evaluate activity and longevity.
  • ◉

    Action Plan:

    1. ◉
      Scaffold a Flutter app with http and shared_preferences.
    2. ◉
      Validate network calls, local storage, basic UI flows.
    3. ◉
      Integrate harmony_next_bridge per its GitCode docs.
    4. ◉
      Build separate APK, IPA, and WebView packages for Harmony Next.

5.2 For Rapid Prototyping and Simple UIs → UniApp / UTS

“

“UniApp can crank out prototypes fast; invest a week to iron out CSS quirks.” — retrocode

  • ◉

    Strengths:

    • ◉
      Single H5‑style codebase; minimal learning curve for web devs.
    • ◉
      Great for dashboards or mid‑back‑office tools.
  • ◉

    Caveat:

    • ◉
      Poor performance under heavy animation; custom JSBridges needed for native calls.
  • ◉

    Action Plan:

    1. ◉
      Define a shared CSS module to unify styling across platforms.
    2. ◉
      Build a JSBridge library for essential features: contacts, camera, file storage.

5.3 Minimal Resources, Maximum Coverage → WebView Shell

“

“You’re two people; WebView wrapping a SPA is your no‑regret fallback.” — [anonymous]

  • ◉

    Strengths:

    • ◉
      Easiest path with existing web expertise; lowest staffing demands.
    • ◉
      Angular, React, or Vue SPAs can deliver decent UX.
  • ◉

    Caveat:

    • ◉
      UX suffers vs. true native; deep hardware integrations need bespoke plugins.

5.4 Native UI + Shared Logic → Kotlin Multiplatform

“

“Share networking and data layers in KMP; write UIs natively per platform.” — implied from original query

  • ◉

    Strengths:

    • ◉
      True native performance; central business logic.
  • ◉

    Caveat:

    • ◉
      Steeper learning curve; best suited for teams familiar with Kotlin/Swift.

5.5 Emerging Options: ovCompose / Compose Multiplatform

“

“Check out ovCompose—Compose support for Harmony Next by Tencent.” — Helsing

  • ◉

    Strengths:

    • ◉
      Leverages Jetpack Compose declarative UI; Tencent has adapted it to Harmony.
  • ◉

    Caveat:

    • ◉
      Still early days; community size unknown.

6. Minimal Viable Demo: Step‑by‑Step HowTo

Below is a HowTo outline to spin up a “three‑end” proof‑of‑concept in Flutter. Adapt as needed for your chosen framework.

"name": "Three‑End Flutter Demo",
"description": "Basic network request, local storage, and contacts access on Android, iOS, Harmony Next",
"steps":
  - "flutter create multi_platform_demo"
  - "Add dependencies: http, shared_preferences"
  - "Implement a ListView fetching JSON from a public API"
  - "Store a simple key‑value pair via SharedPreferences"
  - "Add harmony_next_bridge per GitCode README"
  - "Wrap native contacts API with Dart via JSBridge"
  - "flutter build apk && flutter build ios-framework"
  - "Package a WebView shell for Harmony Next"
  - "Run smoke tests to verify network, storage, contacts"

*(Adapted from the original thread’s request for minimal demos) *

7. FAQ: Quick Answers to Recurrent Doubts

“

Q: Is ArkUI‑X ever production‑ready?
A: Unless you’re willing to build your own plugin hub and reauthor the docs, not today.

“

Q: Can AI tools generate ArkUI‑X code?
A: No—LLMs lack ArkUI‑X context. Generated code tends to reference missing APIs.

“

Q: Two people, four apps—what’s the leanest option?
A: WebView shell for earliest launch; Flutter if UX matters; UniApp for mid‑complexity prototypes.

“

Q: How to vet community plugins?
A: Check last commit date, issue response rate, PR merges. Then build a tiny PoC.

8. Conclusion and Best Practices

  1. Pilot with Flutter: If your product demands smooth interactions, start with Flutter and evaluate harmony_next_bridge.
  2. Lean on UniApp for MVPs: When time is money and features are modest, UniApp delivers.
  3. Reserve KMP for Seasoned Teams: Share logic safely, but prepare for native UI work.
  4. WebView as Insurance: Lowest barrier, fastest to market for internal or data‑entry apps.
  5. Always Proof with PoC: Before full commitment, confirm network, storage, and native call flows.

By focusing on a minimal POC first and iterating based on real test results, even a two‑developer team can conquer three platforms without being trapped by immature ecosystems. Choose your path wisely, avoid the ArkUI‑X quicksand (unless you crave endless adventure), and ship stable, maintainable apps across Android, iOS, and Harmony Next.