The Cross-Platform Story Isn't New
Cross-platform development has been around as long as mobile apps themselves. Back in the PC era, you typed a URL and got a page. Simple. Then the iPhone arrived, and native apps became the gold standard. Apple created the App Store, and that little icon on the home screen changed everything—developers suddenly had a direct line to users.
Then Android showed up, and the industry split into Web, Android, and iOS. Maintaining three codebases meant three teams and triple the cost. Developers started dreaming of writing once and running everywhere.
Facebook tried first with React Native, but performance issues surfaced as apps grew complex. Meanwhile, Google's Chrome engineers noticed their browser was sluggish on mobile—long lists scrolled okay, but white screens popped up too often. They decided to rebuild the rendering pipeline from scratch, focusing on immediate rendering rather than concurrency. That became Flutter.
Flutter's core idea is self-rendering: write in Dart, run on multiple platforms. But it's not without costs. A single Flutter page on a 1080P phone adds roughly 70MB of memory. If you have multiple pages, that overhead stacks up fast.
From Unified UI to Shared Logic
Flutter aims to unify UI; KMP (Kotlin Multiplatform) takes a different route—it shares business logic. This is a generational shift. Instead of trying to make every platform look identical, KMP lets you reuse the code that powers your app's behavior across Android, iOS, and HarmonyOS.
KMP uses an Expect/Actual mechanism. You define a common interface, then provide platform-specific implementations. The granularity can be as coarse as a whole module or as fine as a single function. This flexibility is a big deal for collaboration tools, where teams often need to share complex logic like encryption, data sync, or permission handling without rewriting it for each OS.
Performance-wise, KMP compiles directly to native binaries. It can call platform C interfaces directly, which can lead to several-fold speedups. For a collaboration app that handles real-time messaging or file sharing, that kind of performance matters.
Why Chinese Tech Giants Are Betting on KMP
KMP's adoption in China is closely tied to HarmonyOS. When a company needs to support Android, iOS, and HarmonyOS, hiring three full teams is expensive. KMP offers a way to cut costs while still delivering native performance.
Large apps often split into three domains: performance-critical areas (like checkout flows), dynamic areas (like content feeds that change daily), and open areas (like mini-programs). Historically, performance domains required native development because there was no mature cross-platform framework for logic. KMP changes that.
One head company planned to raise its cross-platform usage from 45% to 75% in two years, but without a logic-sharing solution, they had to run dual tracks: improve JS framework performance while piloting KMP. The takeaway: logic sharing isn't a nice-to-have anymore; it's a necessity.
The Trade-Offs of Cross-Platform Frameworks
Cross-platform frameworks promise efficiency—Flutter typically gives you 1:1.5 productivity, and on HarmonyOS it's about two people doing the work of three. But efficiency isn't free.
First, performance and experience. Frameworks can't deeply customize for each platform. Flutter faces issues with package size, memory, startup time, and native interactions. Cross-language calls add overhead, and multiple runtimes can cause memory leaks if you're not careful.
Second, ecosystem fragmentation. Many companies fork open-source frameworks, creating private versions. When HarmonyOS fixes a bug in Flutter, it's hard to push that fix across all the different forks.
Third, complexity. With a new stack, bugs can live in business code, framework code, or native code. Engineers need to understand the whole chain. There's also the abstraction leak: frameworks try to smooth over platform differences, but you still end up with platform-specific if/else statements in your code.
Cross-platform frameworks don't eliminate complexity; they move it from the business layer to the framework layer. That's a crucial point for teams building collaboration tools—you need to know what you're getting into.
Flutter on HarmonyOS: Optimizations and Limits
HarmonyOS has put real work into making Flutter run better. The Impeller rendering engine pre-compiles shaders, cutting first-frame jank by 100–200ms. Shared memory for external textures avoids copying buffers between GPU contexts, which helped with video playback and VoIP call lag.
But Flutter still has limits. Self-rendering uses more memory, and Dart's concurrency model restricts thread-level sharing. So Flutter can't always match native performance.
KMP on HarmonyOS: Three Key Improvements
HarmonyOS launched its first public KMP version in June 2026, after a year of collaboration with partners. The focus has been on rendering, runtime, and developer productivity.
Half Self-Drawing
Instead of full self-rendering, KMP on HarmonyOS uses a half-drawing approach. Components and text generate draw commands, but the underlying rendering pipeline is native. This reduces memory usage, speeds up startup, and makes it easier to mix native content with cross-platform content.
For example, a single Compose instance might create five buffers. Ten instances could mean 500MB of extra memory. Reusing the native pipeline slashes that.
CMC Garbage Collection
The old GC algorithm caused long pauses and memory fragmentation. HarmonyOS introduced CMC, which divides memory into regions managed by separate threads. A stack map tracks object references, allowing objects to be moved during GC. This spreads out memory cleanup, avoiding those 100ms stop-the-world events.
Think of it like tidying your room regularly instead of waiting until it's a disaster and spending a whole day cleaning.
Parallel Compilation
Compiling KMP used to produce one giant LLVM IR file, which couldn't be parallelized. HarmonyOS splits it into modules, each compiled independently. That gives a 2–4x speedup, though it initially increased package size and hurt runtime performance. They fixed that by caching global variable info and cleaning up unused symbols.
AI Is Changing the Game
AI coding is now a major focus. HarmonyOS is working on A2K (Android to KMP) and D2C (Design to Compose) tools. A2K reuses existing test cases to help the model understand the original code's behavior. It's achieving about a 60% adoption rate for generated code.
D2C initially tried to convert Figma designs directly to Compose, but ran into issues with layer order and hardcoded offsets. The fix? Introduce React as an intermediate representation. React and Compose are structurally similar, and there are plenty of Figma-to-React tools. Splitting the process into two steps improved scores by about 10 points on a 100-point scale.
The lesson: AI coding isn't about taking the shortest path. Sometimes an intermediate step makes a big problem easier to verify.
Choosing the Right Framework for Your Team
So what should you pick? React Native is losing ground—AI can now generate native code, and Meta is already using it less. Flutter is still great if you need consistent UI across platforms and don't mind the performance trade-offs.
KMP makes the most sense for teams targeting Android, iOS, and HarmonyOS, especially if they already have Kotlin code. It compiles to native binaries, so performance is close to native.
Here's a rough guide:
- KMP if you're building for all three platforms long-term.
- Flutter if UI consistency is your top priority.
- React Native only if you have strong dynamic update needs and can handle the ecosystem risks.
But remember: AI generating native code doesn't mean cross-platform frameworks are dead. They still unify logic, reduce debugging across three stacks, and centralize compatibility fixes. In fact, AI might amplify their value—if AI generates code, you want it to generate one version, not three.
The Hybrid Workflow Ahead
Looking forward, the winning combo is likely shared logic plus native UI. KMP handles the heavy lifting of business logic, while native UI delivers the platform-specific experience users expect. AI then amplifies productivity by helping with code migration, UI generation, and testing.
Cross-platform frameworks aren't going away. They're evolving to support both human and AI developers. The key is to pick the right tool for your team's needs and understand the trade-offs. For collaboration tools, where reliability and performance are critical, KMP's shared-logic approach is worth a serious look.
Comments (0)
Please sign in to post a comment.
Don't have an account? Create one
No comments yet. Be the first to comment!