Tencent's Kuikly: Kotlin Multiplatform Framework Achieves Native Performance with Dynamic Updates

Background

Cross-platform development remains a key focus in large-scale frontend engineering, especially with the arrival of HarmonyOS Next increasing demand for comprehensive multi-platform solutions. Existing frameworks struggle to balance three critical dimensions: cross-platform capability, performance, and dynamic updates. Dynamic-language approaches like React Native enable dynamic updates but suffer lower performance due to JS↔VM↔C++↔Native bridging. AOT-compiled self-drawing frameworks like Flutter and JetBrains Compose achieve near-native performance but lack dynamic updates. Flutter/JB Compose also incur larger bundle sizes and engine initialization overhead.

Kuikly, developed and widely used inside Tencent (QQ, Tencent News, QQ Music, Sogou Input, QQ Browser), aims to break these trade-offs by delivering a pure-native cross-platform dynamic solution without an intermediate layer, targeting native-level performance and a native tech-stack development experience.

Capabilities and Advantages

One Codebase, Five Platforms

Kuikly supports Android, iOS, HarmonyOS, Web, and mini-programs. Android and iOS are already open-sourced; HarmonyOS support planned for May, Web and mini-program for Q2.

Native-Level Performance

Leveraging Kotlin Multiplatform (KMP), Kuikly compiles Kotlin code to each platform's native artifacts (.aar for Android, .framework for iOS), achieving execution performance comparable to native. Benchmarks on a complex Feeds-flow demo (included in the open-source repo) show:

First-screen load time matches native across high, mid, and low-end devices.

Memory increment is nearly identical to native because no extra engine is introduced.

Compared to other frameworks, Kuikly leads in both startup and memory usage.

Side-by-side screen recordings on Android and iOS show virtually no perceptible difference between native, Kuikly built-in, and Kuikly dynamic modes.

Kotlin-Driven, Pure Native Toolchain

Development uses Kotlin with native IDEs (Android Studio/VS Code) and native profiling tools. From business code down to framework code, a single unified tech stack handles development, debugging, and performance analysis, creating a closed-loop framework development stack. This contrasts with RN's multi-stack complexity and Flutter's Dart-only tooling.

Declarative + Reactive DSL

Kuikly's custom declarative and reactive DSL boosts UI development efficiency. It uses higher-order functions and type-safe builders for elegant declarative syntax, and property delegation for automatic reactive updates — data changes trigger view updates automatically. Compose DSL support is underway and slated for Q2 open-source, reusing official Compose components, layout, animation, and events while swapping Skia self-drawing for Kuikly's cross-platform native rendering layer.

Page-Level Dynamic Updates

Kuikly supports on-demand switching between built-in and dynamic modes at page granularity, with no hooks and high stability. On Android, dynamic mode uses platform artifacts for near-zero performance overhead even on low-end devices. On iOS and HarmonyOS, dynamic artifacts are JavaScript, performing on par with or better than RN-style frameworks due to a lighter DSL design.

Lightweight, Stable, Maintainable

The framework is designed with minimal external dependencies, enhancing stability and maintainability. Bundle-size increment comparison shows Kuikly adding significantly less overhead than Flutter or RN.

Implementation Principles and Architecture

Technology Selection Rationale

The team evaluated multiple cross-platform languages and settled on KMP because:

Kotlin is Android's official language, offering low learning curve and native toolchain/ecosystem compatibility.

KMP compiles Kotlin to platform-native binaries (JVM/ART bytecode on Android, native binaries on iOS) for high-performance multi-platform execution.

KMP can also compile to JS/Wasm, enabling dynamic code updates.

Architecture Overview

Cross-Platform Core Layer

DSL-driven: Custom declarative+reactive Kuikly DSL and standard Compose DSL (in progress).

BuildTree: High-performance core mapping DSL component tree to native UI tree, featuring a two-tree mapping scheme, fine-grained O(1) diff update algorithm, and rendering instruction generation.

Unified Widgets: Ensures cross-platform consistency by re-implementing complex high-level components (ListView, ViewPager, Waterfall, etc.) in the cross-platform layer; only a few native atomic components map directly via a unified interface layer.

Layout Engine: Uses the mature Yoga engine for FlexBox layout support.

Native Rendering Layer (Lightweight)

Unified Platform Interface: Standardizes native capability interfaces across platforms.

Native UI Mapping: Minimal atomic rendering components — only Text, Image, Input, ScrollView, etc. — reside in the native layer.

API Implementation Module: Provides platform-specific extensions for unified APIs consumed by the cross-platform layer.

Communication between Core and Render layers avoids KMP's actual/expect direct dependency, instead using a callKotlin/callNative instruction-based scheme. This achieves compile-time isolation between the Kotlin cross-platform layer and the native rendering layer, enabling dynamic updates of the cross-platform layer (Core + business code).

KuiklyBase Infrastructure

Includes HarmonyOS Kotlin/Native adaptation for high-performance HarmonyOS execution (May open-source), cross-platform base components extended to HarmonyOS (May), a full development toolchain covering scaffolding, debugging, building, release, and monitoring, and stack-capture/reporting capabilities for efficient crash diagnosis.

Key Technical Deep Dives

Two-Tree Rendering Principle

Typical rendering pipelines involve four steps: create ViewTree, measure, layout, draw. To preserve pure native rendering experience, Kuikly keeps draw in the native layer and performs the first three steps in platform-agnostic Kotlin. Unlike Flutter/RN's three-tree (virtual DOM) approach, Kuikly maps the cross-platform DSL tree directly to the native render tree, yielding a lighter rendering mechanism.

Rendering instructions abstract create/update/delete operations per platform; calling each platform's implementation of these abstract interfaces builds consistent UI across ends.

High-Consistency Native Rendering

Kuikly chose native rendering over self-drawing for better toolchain support, closer-to-native interaction, and smaller bundle size. To solve native rendering's historical cross-platform inconsistency, Kuikly's lightweight native layer provides only minimal atomic components (Text, Image, Input, ScrollView). High-level components are composed like building blocks in the Kotlin cross-platform layer, ensuring logic consistency.

Declarative Reactive DSL

Inspired by Compose/SwiftUI, Kuikly leverages Kotlin's strengths:

Higher-order functions and type-safe builders for declarative syntax.

Property delegation for automated reactive update system.

This design lets model changes automatically trigger view updates while keeping code concise and maintainable. A typical Kuikly page example demonstrates the DSL in action.

Kuikly started early when Compose adoption was low and dependency requirements high, prompting a custom DSL. With Compose's growing popularity and AI-coding/ecosystem alignment needs, Kuikly now supports Compose DSL by reusing official Compose high-level capabilities while redirecting rendering to Kuikly's native view drawing layer. This preserves Compose APIs, enables rapid adaptation to HarmonyOS/Web/mini-program via Kuikly's rendering layer, and naturally inherits Kuikly's dynamic update capability for Compose syntax.

Extreme Rendering Performance Optimization

Beyond the rendering pipeline, Kuikly optimizes rendering instruction volume, node volume, and direct instruction emission.

Precise Diff

Diff algorithms compare old/new component trees to find minimal update sets. Kuikly rewrites Kotlin control-flow statements (if/else if/else, for loops, when expressions) into Patch instructions, achieving precise diff for extreme-performance scenarios.

UI Flattening

Deep UI hierarchies increase measure/layout cost and cause jank. Borrowing from RN and combining with its two-tree design, Kuikly renders only visible nodes:

The prototype tree introduces a renderable-node interface; subclasses implement whether they need rendering.

Layout-only View nodes return non-renderable, avoiding native widget mapping.

During prototype-tree sync, non-renderable nodes are dropped; only renderable nodes are kept to maintain the RenderTree for 1:1 widget mapping.

Dynamic Updates

Designed from the start for dynamic scenarios, Kuikly's comprehensive decoupling lets business code compile independently to platform-specific executables. Cross-platform code and platform code can either direct-call or decoupled-dynamic-call, enabling both built-in and dynamic modes on demand. Android dynamic mode uses platform artifacts for near-native execution efficiency; iOS/HarmonyOS use JavaScript, matching or exceeding RN-style frameworks thanks to a lighter DSL.

KuiklyBase Infrastructure

KuiklyBase is the accumulated cross-platform development foundation:

HarmonyOS Kotlin/Native adaptation for high-performance HarmonyOS execution (May open-source).

Cross-platform base components extended to HarmonyOS, continuously enriching component ecosystem (May).

Full development toolchain covering scaffolding, debugging, building, release, monitoring.

Stack capture and reporting for efficient dev-time stack restoration and precise production crash monitoring.

Roadmap

Near-Term Open-Source Plans

HarmonyOS: May.

H5 and mini-program platforms: Q2.

Compose DSL support: Q2.

Future Plans

Framework capability enhancements: tooling improvements, more platforms (Windows/macOS desktop), internationalization support.

Community ecosystem: component platform, community engagement.

GitHub repository: https://github.com/Tencent-TDS/KuiklyUI Official documentation:

https://kuikly.tds.qq.com/%E7%AE%80%E4%BB%8B/arch.html