Why Chinese Tech Giants Are Betting on KMP for HarmonyOS

The Return of the Cross-Platform Dream

Cross-platform development isn't a new story. In the PC era, a URL in a browser was all you needed. Then the iPhone arrived, and native apps became the way to deliver mobile experiences. Apple built the App Store, and that little icon on the home screen changed everything. Developers suddenly had a direct channel to users, and the mobile app gold rush began.

Android followed, and the industry split into Web, Android, and iOS. Maintaining an app across all three meant multiple codebases, multiple teams, and multiplied costs. Developers started longing for the good old days of "write once, run anywhere."

Facebook answered with React Native, bringing web paradigms to mobile. But as apps grew complex, performance suffered. Meanwhile, Google's Chrome engineers were wrestling with their own mobile problems. Chrome's desktop-first architecture was a poor fit for mobile CPUs. Long lists scrolled okay, but white screens appeared far too often—a bug on mobile, even if acceptable on the web.

So they rebuilt the rendering pipeline from scratch. The goal shifted from maximizing concurrency to instant rendering. Content had to appear immediately, not whenever the system got around to it. A shorter pipeline also made debugging easier. That was the birth of Flutter.

From Unified UI to Shared Logic

Flutter's core is self-rendering. Write Dart once, run on Android, iOS, and the web. Later, Impeller replaced Skia, using Vulkan for better GPU performance. But Dart never gained huge traction in China, where many teams experimented with JavaScript or TypeScript alternatives like Tencent's MXFlutter. Some even argued Flutter would be more successful if it used JavaScript.

Kotlin Multiplatform (KMP) takes a different approach. Instead of unifying the UI, it focuses on sharing business logic. Flutter uses Platform Channels to call native features, but as complexity grows, you end up with a mess of channel code. Serialization and deserialization between languages can cause performance hits, especially in high-frequency interactions.

KMP introduces the Expect/Actual mechanism. You define a common interface, then provide platform-specific implementations. The granularity can be as coarse or as fine as you need—down to individual functions or properties. This gives you both development efficiency and direct access to native APIs. KMP compiles to native binaries, so performance can be several times better, sometimes nearly 100x, compared to bridge-based approaches.

Why China Is Going All In on KMP

KMP's adoption in China is closely tied to HarmonyOS. When you need to support Android, iOS, and HarmonyOS, you can't just hire three separate teams. The cost is prohibitive. A typical large mobile app can be split into three zones:

• Performance zone: Core flows like browsing to checkout. These need high performance and stability, often using native or KMP.
• Dynamic zone: Content pages where operators want to push updates daily. Performance matters less, so frameworks like Lynx or Weex work.
• Open zone: Super-apps that want to host third-party mini-programs, like WeChat or Alipay.

Historically, the performance zone had to be native because no mature cross-platform framework could deliver the required performance. C++ is memory-intensive, Rust has a steep learning curve, and JavaScript or Dart hit performance ceilings. Kotlin and Cangjie (Huawei's language) showed promise, but Kotlin lacked iOS and HarmonyOS infrastructure, and Cangjie was too young.

One major app planned to increase its cross-platform share from 45% to 75% in two years but couldn't because logic sharing wasn't possible. That's why logic sharing has become a real need, not just a nice experiment.

HarmonyOS, as a newcomer, has to be more accommodating. To attract developers, it opened up C APIs to support KMP. When React Native was being adapted, the system even rushed to provide C APIs to compensate for ArkTS's performance limitations in bridging.

The Cost of Cross-Platform: Efficiency vs. Experience

Cross-platform frameworks boost efficiency—Flutter typically gives a 1:1.5 ratio, and on HarmonyOS it's about two people doing the work of three. But that efficiency isn't free.

First, performance and experience suffer. Frameworks can't deeply optimize for each platform. Flutter, for instance, faces issues with package size, memory usage, startup time, and native interactions. Cross-language calls add overhead, and multiple runtimes can create complex object lifecycle problems. React Native and Android native code can reference each other, leading to memory leaks.

Second, ecosystem fragmentation. Many Chinese companies fork open-source frameworks for their own needs. When HarmonyOS fixes a Flutter bug, getting that fix into every fork is a nightmare.

Third, technical complexity. When something breaks, the issue might span business code, the framework, and the native system. Engineers must understand the entire stack. And there's the "leaky abstraction" problem—you can't fully hide platform differences, so you end up with platform-specific if/else statements anyway.

Cross-platform frameworks move complexity, but they don't eliminate it. The complexity just shifts from the business layer to the framework layer.

Flutter on HarmonyOS: Adaptation and Optimization

HarmonyOS had to adapt Flutter's runtime, UI, cross-language calls, third-party libraries, and command-line tools. Third-party libraries were the biggest chunk—thousands of them. In 2025, they rushed to adapt the top 30, and coverage kept expanding.

Two major optimizations stand out. First, Impeller now pre-compiles shaders at build time, eliminating the 100–200ms runtime compilation that caused frame drops on first render. With Vulkan, GPU utilization improved, and CPU load dropped.

Second, they introduced shared memory for external textures. When a camera or player produces an image, it used to be copied between GPU contexts. Now, the buffer is shared, reducing overhead and fixing stuttering in video calls and VoIP.

But Flutter still has hard limits. A single Flutter page on a 1080p phone adds about 70MB of memory. With N pages, that's N×70MB. And Dart's concurrency model lacks true shared memory between threads, so Flutter can't always match native performance.

KMP on HarmonyOS: Three Key Improvements

HarmonyOS and partners started building KMP support in 2025. Early feedback was rough: cross-language communication, memory usage, debugging, package size, and compilation speed were all problematic. By June 2026, they released the first public version, and more fixes are planned by September 2026.

Half-Rendering: A Middle Ground

Flutter uses self-rendering, which causes memory bloat and mixing issues. A new approach is "half-rendering": components and text still generate drawing commands, but the underlying rendering pipeline is native. This avoids duplicating GPU contexts and buffer memory. For example, a single Compose instance might need five buffers; with ten instances, that's 500MB. Reusing the native pipeline slashes that.

It also enables deeper vertical integration. If only a part of the page moves, you can cache the subtree and just call transform, avoiding a full redraw.

CMC: Reducing GC Stalls

KMP on HarmonyOS and iOS initially used a GC algorithm similar to early CMS. It caused long pauses and memory fragmentation. When the heap becomes fragmented, the system must stop-the-world and compact memory, causing 50–100ms freezes.

HarmonyOS developed CMC to fix this. It divides memory into regions, each managed by separate threads, improving concurrency. It also uses Stack Maps to track object references, allowing objects to be moved safely. Compaction now happens incrementally, like cleaning your room regularly instead of waiting until it's a disaster.

Parallel Compilation: 2–4x Faster Builds

Previously, KMP compiled all Kotlin files into one massive LLVM IR file, then optimized globally. That couldn't be parallelized. HarmonyOS split it into multiple IR modules, enabling parallel compilation. But that increased package size and hurt performance. They fixed it by recording only necessary exports and caching global variable info. Result: build times dropped by 2–4x.

AI Coding: The New Workflow

HarmonyOS is also exploring AI-assisted development, focusing on A2K (Android to KMP) and D2C (Design to Compose).

A2K faces three challenges: huge codebases, quality control, and proprietary knowledge. To handle this, they reuse existing test cases to help the model understand behavior, and they extract base modules so generated code works in the real environment. Adoption rate for A2K-generated code is about 60%.

D2C initially converted Figma designs directly to Compose, but that failed due to z-order issues and hardcoded offsets. The fix? Introduce React as an intermediate representation. React and Compose are structurally similar, and there are many Figma-to-React tools. Splitting the process into two steps improved scores by about 10 points on a 100-point scale. Plus, you can debug the intermediate React code in Chrome.

The lesson: more steps isn't always worse. A stable intermediate representation turns one big problem into two smaller, verifiable ones.

Which Framework for the AI Age?

AI changes the calculus. React Native faces the biggest threat. Its main selling point was letting web developers build mobile apps, but AI can now generate native code, making that advantage less compelling. Its dynamic capabilities are still useful, but H5 can do similar things. Meta is already reducing its use.

Flutter remains strong for UI consistency across platforms. If you care about a uniform look and don't need native UI or extreme performance, Flutter is fine.

KMP is best for the three-platform Chinese market. It reuses Kotlin code, and many companies already have large Kotlin codebases. It compiles to native binaries, so performance is close to native.

AI can generate code, but that doesn't make cross-platform frameworks obsolete. One company, after cutting staff by 50%, used AI to fill gaps and KMP to unify its stack. Another is switching its AI coding target to KMP. Why? Because if AI generates three separate codebases, engineers still need to understand three stacks. A cross-platform framework reduces that burden, and with AI, the leverage only grows.

Frameworks also centralize compatibility fixes. Android's fragmentation means many issues shouldn't be fixed by each business team.

The core question is shifting from "how to help developers write multi-platform code" to "how to help AI generate high-quality, verifiable, reusable multi-platform code." That requires better abstractions, more test assets, stable toolchains, and an ecosystem that AI can understand.

Looking Ahead: Shared Logic, Native UI, and AI

In China, KMP's shared logic and HarmonyOS's growth are a natural fit. It leverages existing Kotlin code and reduces the cost of adding HarmonyOS support. But for apps that demand the best experience, UI reuse isn't always ideal. Flutter or Compose Multiplatform can't fully replicate iOS's native transitions or Android's ripple effects. Native UI still matters.

Over the next three years, the mainstream approach will likely be shared logic plus native UI. AI will handle requirements, migration, UI generation, testing, and performance alignment. Native UI provides platform experience, KMP shares logic, and AI amplifies efficiency.

Cross-platform frameworks won't disappear just because AI can code. They need to redesign their abstractions, tools, and ecosystems so both humans and AI can work within a unified, reliable system.