Cross-Platform Sports Apps: How KMP and HarmonyOS Are Changing the Game

The Evolution of Cross-Platform Development

Cross-platform development isn't a new story. It's been around since the PC era, when a URL was all you needed to jump between pages. Then the iPhone arrived, and native apps became the gold standard. The App Store's little icon gave developers a direct line to users, and suddenly everyone wanted in.

Android followed, and the industry split into Web, Android, and iOS. Maintaining three separate codebases meant three teams and triple the cost. Developers started dreaming of "write once, run anywhere" again.

Facebook answered with React Native, but performance suffered as apps grew complex. Meanwhile, Google's Chrome engineers noticed their browser was terrible on mobile. The desktop architecture choked on limited CPU resources, causing frequent white screens. So they rebuilt the rendering pipeline from scratch—prioritizing immediate rendering over concurrency. That's how Flutter was born.

The Shift from Unified UI to Shared Logic

Flutter's core is self-rendering. You write Dart once, and it runs on Android, iOS, and Web. Later, Impeller replaced Skia to fix shader compilation stutters. But self-rendering has limits: each Flutter page can eat up to 70MB on a 1080P phone, and Dart's concurrency model still has restrictions.

KMP (Kotlin Multiplatform) takes a different route. Instead of trying to unify UI, it shares business logic across platforms. With Expect/Actual, you define common interfaces and provide platform-specific implementations. This granularity lets you reuse code from whole modules down to individual functions, and it calls native C interfaces directly, giving performance close to native.

Why Chinese Tech Giants Are Betting on KMP

HarmonyOS is a big reason. Companies now need to support Android, iOS, and HarmonyOS—three platforms, but they can't afford three full teams. A large app typically splits into three zones: performance-critical (like shopping carts), dynamic (like content feeds), and open (like mini-programs).

For performance zones, native or KMP is the go-to. C++ is memory-hungry, Rust has a steep learning curve, and JavaScript/Dart hit performance ceilings. Kotlin, with its strong Android ecosystem and growing HarmonyOS support, becomes a practical choice.

One leading app planned to raise cross-platform coverage from 45% to 75% in two years. Without logic-sharing, they had to run two tracks: boost JS frameworks and pilot KMP and Cangjie. Logic sharing has gone from a nice-to-have to a necessity.

The Cost of Efficiency: Performance and Complexity

Cross-platform frameworks boost efficiency—Flutter typically gives 1:1.5, and on HarmonyOS it's like two people doing three people's work. But there's a price:

• Performance: generic frameworks can't deeply optimize for each platform. Flutter deals with package size, memory, and native interaction issues.
• Ecosystem fragmentation: many companies fork open-source frameworks, making it hard to push fixes back.
• Technical complexity: debugging spans business code, framework, and native system. Abstract leaks mean platform-specific if/else still creeps in.

Frameworks shift complexity from business to framework layer, but they don't eliminate it.

Flutter on HarmonyOS: Adaptations and Optimizations

HarmonyOS had to adapt Flutter's runtime, UI, cross-language calls, and third-party libraries. The biggest chunk was libraries—they urgently ported the top 30 core ones in 2025.

Impeller pre-compiles shaders, cutting first-frame jank from 100-200ms. Using Vulkan, it better utilizes GPU parallelism, boosting frame rates and lowering CPU load.

For external textures like camera or video, HarmonyOS introduced shared memory. Instead of copying buffers between GPU contexts, both rendering pipelines share the same memory, slashing overhead and fixing stutter in WeChat video and VoIP calls.

Still, Flutter's self-rendering memory footprint remains. Each Flutter page adds ~70MB; ten pages could cost 700MB. And Dart's threading limits mean it can't always match native performance.

KMP on HarmonyOS: Three Key Upgrades

Starting 2025, Huawei and partners pushed KMP on HarmonyOS. The first public version arrived in June 2026, supporting full apps. Three major improvements:

From Self-Rendering to Semi-Drawing

Flutter's self-rendering causes memory bloat and native mixing issues. KMP now uses a "semi-drawing" approach: components generate draw commands, but the bottom uses the native rendering pipeline. Benefits: no duplicate GPU context, faster startup, and smoother native mixing. One Compose instance used to create ~5 buffers; ten instances could hit 500MB. Reusing the native pipeline cuts that drastically.

CMC Garbage Collection

KMP's old GC was like early CMS—long pauses and memory fragmentation. It couldn't distinguish pointers from data, so objects couldn't move safely. Eventually, a Stop-the-World pause could last 50-100ms.

HarmonyOS built CMC: memory is divided into regions, each managed by separate threads for better concurrency. Stack Maps record references, allowing safe object movement during GC. Fragmentation is handled continuously, like cleaning your room daily instead of a yearly purge.

Parallel Compilation

KMP used to compile all Kotlin into one giant LLVM IR file, which couldn't parallelize. Splitting it into modules brought 2-4x faster builds, but initially increased package size and hurt performance. By caching global variable info and cleaning up unused symbols, they fixed both issues.

AI Coding: The New Frontier

AI is reshaping how we build cross-platform apps. For KMP, the focus is on A2K (Android to KMP) and D2C (Design to Compose).

A2K reuses existing test cases to help the model understand behavior. It extracts base modules and embeds them into generated code, achieving a 60% adoption rate.

D2C originally tried to convert Figma directly to Compose, but hit z-order errors and fixed offsets. They introduced React as an intermediate representation. React's declarative nature aligns with Compose, and the ecosystem has mature Figma-to-React tools. This two-step process improved scores by ~10 points in one evaluation.

AI isn't about skipping steps—it's about breaking big problems into verifiable chunks.

Choosing a Framework in the AI Era

AI changes the calculus. React Native loses its edge as AI can generate native code directly. Its dynamic capabilities are still useful, but Meta is already pulling back. For new projects, be cautious.

Flutter remains strong for UI consistency across platforms. If you need pixel-perfect visuals and can tolerate some performance trade-offs, it's still a solid choice.

KMP fits the Chinese three-platform reality. It reuses Kotlin code, generates native binaries, and performs close to native. Many companies, even after layoffs, are consolidating on KMP to simplify maintenance and let AI handle more.

The real question isn't whether cross-platform frameworks survive AI—they will. It's how they adapt. They need better abstractions, richer test assets, and toolchains that AI can understand. In the end, expect a hybrid: native UI for platform feel, KMP for shared logic, and AI amplifying developer productivity.