How Taro on Harmony Boosts Mobile App Development with Multi‑Threaded Performance

Background

Pure‑blood HarmonyOS is becoming the world’s third‑largest operating system, prompting a wave of native adaptations; JD, as a national‑level app, must provide a complete shopping experience for Harmony users.

In September last year, the JD APP for pure‑blood Harmony launched in the Harmony App Store. Core shopping flows—home, search, product detail, cart, order, checkout, and My JD—were built with the Taro on Harmony solution and immediately received Huawei’s S‑level app certification.

Taro Introduction

Taro is an open‑source cross‑platform solution initiated and maintained by JD, enabling developers to write mini‑programs, H5, and native apps using a Web‑style development paradigm. Since its 2018 open‑source launch, it has amassed over 36,000 GitHub stars.

Over the past year, Taro completed the Harmony adaptation, allowing developers to use a React DSL to quickly build high‑performance native Harmony apps. A single codebase now targets Harmony, mini‑programs, H5, and React Native, dramatically lowering the development barrier and enabling existing Taro projects to be ported to native Harmony, saving substantial R&D costs.

Evolution of Taro on Harmony Adaptation

Initial version based on ArkTS

The first adaptation linked Taro to Harmony’s native ArkTS language, similar to the WeChat mini‑program solution. It simulated a browser DOM/BOM environment, executed React code to build a virtual DOM, then recursively traversed it to construct the host rendering tree for Harmony.

This approach suffered noticeable performance loss because an extra conversion layer was added on top of ArkTS.

New version based on C API

Harmony later opened a lower‑level C API, providing C++ UI node creation and property setting capabilities similar to a C++ DOM. This matched Taro’s architecture perfectly: the virtual DOM generated by Taro React could directly create native UI nodes via the C API, moving most rendering pipeline work to C++ and achieving a performance leap.

Single‑threaded architecture version

The rendering process runs entirely on the main thread: business code executes in ArkVM to obtain a virtual DOM, style data is read, React Reconciler invokes NAPI to build the native Element Tree in C++, parses styles into a CSSOM, matches Element Tree with CSSOM to create a styled Render Tree, generates Yoga layout nodes, and finally produces a C API ArkNode Tree for screen rendering.

JD’s Harmony app’s home, search, My JD, and core shopping flow currently use this single‑threaded version, delivering top‑tier performance and stability.

Multi‑threaded architecture version

After the single‑threaded version launched, limitations emerged: all business code execution and rendering occurred on the main thread, causing overload, UI jank, and preventing dynamic code updates.

To address these issues and further improve performance, a multi‑threaded architecture was implemented.

Compared with the single‑threaded approach, the multi‑threaded design splits business code execution and rendering across three threads, preventing main‑thread blockage and offering three key benefits:

Business logic no longer blocks the main flow , eliminating freezes and improving page smoothness.

Animations run without jank , managed by a background thread for full‑frame rendering.

Dynamic update capability , matching native performance while allowing remote JS resource updates for rapid feature verification without full releases.

The multi‑threaded version is currently being piloted and will be released soon.

Features of Taro on Harmony

Rich capability support

Common components and API support

The C‑API version of Taro for Harmony fully supports React 18+, about 33 components (View, Text, Image, Video, etc.), and common APIs such as getSystemInfo and getStorage. Complex APIs like createSelectorQuery and createIntersectionObserver have been re‑implemented in C++ for significant performance gains.

Common style support

The C‑API version supports most CSS features:

Standard CSS styles and layout, including flex, pseudo‑classes, and pseudo‑elements.

Common positioning: absolute and fixed.

Selectors and media queries.

Units like vh, vw, and calc.

CSS variables and safe‑area definitions.

A custom CSSOM implementation in C++ handles style parsing, matching, synthesis, and application, mirroring browser behavior.

Taro also integrates the Yoga layout engine to ensure rendering styles align with W3C specifications.

High performance comparable to native ArkTS

Runtime logic down to C++

In the C‑API version, the ArkVM‑side runtime is minimized, with most TaroElement logic shifted to C++. Parent‑child bindings are removed, dramatically boosting performance.

On the C++ side, Taro imperatively calls ArkUI C++ APIs to efficiently create nodes, set properties, bind events, and render to screen.

Long‑list component for large‑data scenarios

Taro provides a specialized long‑list component with lazy loading, pre‑loading, and node reuse, effectively handling massive data sets and improving fluidity.

C‑API mixed native rendering mode

When certain components or APIs are unavailable in Taro, the C‑API version supports hybrid development, allowing native pages or components to be compiled into Taro Harmony projects and mixed with Taro components on the same page.

Conclusion

The Taro Harmony solution, built on Harmony C‑API, connects the React DSL directly to C++ for a rendering pipeline that matches native performance. Its multi‑threaded architecture delivers industry‑leading rendering speed and responsiveness, while dynamic update capability makes it a pioneering framework validated by large‑scale app deployments.

Ongoing work includes exploring React C++ implementation, self‑developed layout engines for richer styling, and developer tools such as hot‑reload, source mapping, breakpoint debugging, and element inspection to further boost efficiency.

In the near future, JD will open‑source the proven single‑threaded version to contribute to the community and strengthen the Harmony ecosystem.