# Tencent KuiklyUI: Kotlin Multiplatform UI for Six Targets

> KuiklyUI is Tencent's Kotlin Multiplatform UI framework that compiles one codebase to native binaries for Android, iOS, HarmonyOS, Web, Mini Programs and macOS. It is a serious option for teams already invested in Kotlin, and a hard sell for anyone else.

**Tencent-TDS/KuiklyUI** — A Kotlin Multiplatform UI framework from Tencent TDS — high-performance, one codebase for six platforms, with dynamic delivery.

- Repository: https://github.com/Tencent-TDS/KuiklyUI
- Website: https://kuikly.tds.qq.com/home
- Stars: 3,543 · Forks: 309
- Language: Kotlin
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/tencent-tds-kuiklyui

## What KuiklyUI solves, and who it is actually for

The problem is the one every multi-surface product team hits: the same screen has to exist as an Android view hierarchy, an iOS view hierarchy, a HarmonyOS ArkUI tree, a web page and a mini program. KuiklyUI's answer is to write that screen once in Kotlin and have the build produce platform-native artifacts rather than a web view or a JavaScript bridge. The README states the framework generates platform-native binaries with the extensions .aar for Android, .framework for Apple platforms and .so for HarmonyOS, and that the SDK footprint is roughly 300KB on Android and 1.2MB on iOS in AOT mode.

The audience is narrower than the platform list suggests. This is for teams that already have Kotlin in their stack and ship to several of the six targets. The README names QQ, QQ Music, QQ Browser, Tencent News, Sogou Input Method, WeSing, Kugou Music, Kuwo Music and others as users, which tells you the intended scale: large consumer apps with several client platforms and a shared front-end organisation. A single-platform Android app gains nothing here. The framework's whole value proposition is amortising one codebase across targets, and with one target there is nothing to amortise.

## How the core, the renderers and the KSP step fit together

The repository layout makes the architecture legible. A core module holds the cross-platform logic: responsive UI, layout algorithms and Bridge communication. Inside it, source sets split by target: commonMain defines the cross-platform interfaces, androidMain produces the .aar, jvmMain is generic JVM code with no Android APIs and produces a .jar, appleMain covers iOS and macOS and produces a framework, ohosArm64Main produces the .so, and jsMain covers H5 and Mini Programs and produces JavaScript.

Rendering is deliberately not in core. Separate modules exist per platform: core-render-android, core-render-ios, core-render-ohos and core-render-web. That split is the design decision worth noticing. The shared layer decides what the UI should look like; each renderer turns that into the host platform's native drawing calls. It is why the README can claim native rendering rather than a canvas painted by a cross-platform engine.

Two more modules matter for day-to-day work. core-annotations defines business-facing annotations such as @Page, and core-ksp is the annotation processor that generates the Core entry files. That means pages are not registered by hand; the build reads your annotations and emits the wiring. A separate core-kapt module exists alongside core-ksp, which suggests the project has carried both annotation-processing paths.

The compose directory is a second, parallel UI layer. The README states it contains cross-platform source based on Jetpack Compose 1.7.3, modified to fit Kuikly's rendering requirements, with the package renamed from androidx.compose to com.tencent.kuikly.compose and some features commented out. The stated reason is to keep future upgrades manageable and avoid conflicts with upstream code. That is an honest trade-off to document, and it also means the Compose layer is a fork you inherit rather than a dependency you upgrade.

## Installing KuiklyUI and running the Android demo

The README does not publish a Gradle coordinate to depend on. Getting started means cloning the repository and building the sample host apps, with integration into your own project covered by a separate Integration Guide on the documentation site. The environment requirements are explicit: JDK17, Android Studio, Xcode with cocoapods, and DevEco Studio 5.1.0 or newer with API Version 18 or above for HarmonyOS.

There is one version trap worth flagging. The README warns that if your Android Studio version is 2024.2.1 or newer, the default Gradle JDK is 21, which it says is incompatible with the project's configuration, and you must switch it to 17 through Settings, Build, Execution, Deployment, Build Tools, Gradle, Gradle JDK.

Once the environment is ready, the Android path is to open the repository root in Android Studio, sync, and run the androidApp configuration:

```bash
# In Android Studio: open the KuiklyUI root directory, sync the project,
# then select the androidApp configuration and Run 'androidApp'
```

The iOS path has an extra step because the host app uses CocoaPods. From the iosApp directory:

```bash
cd iosApp
pod install --repo-update
```

After that, the README says to open the repository root in Android Studio, sync, and run the iOSApp configuration, or alternatively open KuiklyUI/iosApp directly in Xcode. It also documents a failure mode specific to Xcode: the iosApp project runs a KMP script at compile time, and if the script hits read and write permission errors, you must set User Script Sandboxing to No under Xcode, Build Setting.

For a first real use, the README points to the demo directory as DSL example code and to the Quick Start page for a hello-world. The annotation-driven entry point is @Page from core-annotations, with core-ksp generating the Core entry files at build time. The repository also ships a small Node static server used by the web and mini program hosts, runnable through the scripts in package.json:

```bash
npm run serve
```

That server is tooling for the sample hosts, not part of the framework runtime.

## Where KuiklyUI is the wrong choice

The platform maturity labels are the first limitation, and they come from the README itself. Web and Mini Programs are marked Beta. macOS is marked Alpha. Only Android, iOS and HarmonyOS are listed without a qualifier. If your roadmap includes a macOS desktop client or a production web build, you are adopting a component the project does not yet describe as finished.

The Compose layer is a fork, not a dependency. The README says the code is based on Jetpack Compose 1.7.3 with necessary modifications, a renamed package and some features commented out. Practically, that means Compose Multiplatform release notes do not translate directly into KuiklyUI upgrades, and any fix you need upstream may have to be reapplied by hand into the fork.

The build surface is wide. There are per-Kotlin-version build scripts in the root, from build.1.3.10.gradle.kts through build.2.1.21.gradle.kts, plus matching settings files and a separate build.2.0.ohos.gradle.kts. The README claims Kotlin 1.3.10+ support while the badge pins Kotlin 2.1.21. That spread is useful if you are stuck on an old Kotlin, but it also means the project maintains many configurations, and a bug in your particular combination may be a combination few others use.

Finally, the licence is not an OSI identifier. The repository metadata reports NOASSERTION, and the badge links to a file named KuiklyUI License rather than Apache 2.0 or MIT. That is not automatically disqualifying, but it removes the assumption of a well-understood permissive grant. For a framework you intend to ship inside a commercial client, that file needs reading before anything else.

## KuiklyUI and Compose Multiplatform: two different bets

The natural comparison is JetBrains Compose Multiplatform, and the difference is structural rather than a matter of features. Compose Multiplatform is the upstream project; KuiklyUI's compose module is derived from Jetpack Compose 1.7.3 and adapted to Kuikly's rendering pipeline, with the package renamed to com.tencent.kuikly.compose. Choosing KuiklyUI means choosing a downstream fork with its own release cadence, currently visible in the 2.28.0, 2.27.0 and 2.26.0 releases.

The second difference is the target list. Compose Multiplatform's centre of gravity is Android, iOS, desktop and web through Kotlin/Wasm. KuiklyUI's README lists Android, iOS, HarmonyOS, Web, Mini Programs and macOS. HarmonyOS and Mini Programs are the targets that stand out, and they are the reason a Chinese-market product team would look here at all. If you need to ship a HarmonyOS Next client alongside Android and iOS from one codebase, that combination is the specific gap KuiklyUI targets.

The third difference is the rendering approach. KuiklyUI separates core from per-platform renderers (core-render-android, core-render-ios, core-render-ohos, core-render-web) and describes native UI rendering with native binaries. That is a different bet from rendering through a shared canvas or through the platform's own Compose implementation, and it is the claim the README leads with under Key Features.

## Maintenance, releases and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-23. Recent releases are 2.28.0 on 2026-09-16, 2.27.0 on 2026-09-03 and 2.26.0 on 2026-08-27, which is a roughly two-week cadence across those three tags. That cadence is the practical maintenance signal here.

The upgrade cost is not just a version bump. Because the compose module is a modified fork of Jetpack Compose 1.7.3, and because the root carries build scripts for many Kotlin versions, an upgrade can touch the Kotlin version, the Gradle build script selection, the annotation processor path (core-ksp, with core-kapt also present) and the Compose fork. The README's note that some Compose features are commented out to facilitate future upgrades tells you the maintainers are actively managing that fork, and that bringing a commented-out feature back is work someone has to do.

On licensing: the repository metadata reports NOASSERTION and the badge points at a KuiklyUI License file. This article cannot tell you what that licence permits. What can be said is that a custom licence is a review item, not a formality, and that the review should happen before the first line of production code rather than after.

## Conclusion

Adopt KuiklyUI if your team already writes Kotlin, ships to at least three of the six supported targets, and can absorb a Gradle and Kotlin version matrix plus a custom licence review. Do not adopt it for a single-platform app or a team without Kotlin experience, since the framework's value is in code reuse across targets, not in replacing one native toolkit. Before committing, verify three things: that the KuiklyUI License permits your distribution model, that your toolchain matches the documented requirements (JDK17, Kotlin 2.1.21 in the README badge, Gradle JDK set to 17 in Android Studio 2024.2.1 or newer), and that the platform you care about is past Beta or Alpha. Web and Mini Programs are marked Beta and macOS Alpha in the README, so treat them as evaluation targets rather than production ones.

## FAQ

### Which platforms does KuiklyUI support?

The README lists Android, iOS, HarmonyOS, Web (Beta), Mini Programs (Beta) and macOS (Alpha). The Beta and Alpha labels are the project's own, so only Android, iOS and HarmonyOS are listed without a maturity qualifier.

### What are the system requirements for building KuiklyUI?

The README lists iOS 12.0+, macOS 10.13+, Android 5.0+, HarmonyOS Next 5.0.0(12)+ and Kotlin 1.3.10+. The build environment section also requires JDK17, Android Studio, Xcode with cocoapods, and DevEco Studio 5.1.0 or newer with API Version 18 or above.

### Why does the Android build fail in newer Android Studio versions?

The README states that Android Studio 2024.2.1 and newer defaults the Gradle JDK to 21, which it says is incompatible with the project's configuration. The fix it gives is to set Gradle JDK to 17 under Settings, Build, Execution, Deployment, Build Tools, Gradle, Gradle JDK.

### Does KuiklyUI use Jetpack Compose?

The compose module is based on Jetpack Compose 1.7.3 with modifications for Kuikly's rendering requirements, and the package name is changed from androidx.compose to com.tencent.kuikly.compose. The README notes some features are commented out to make future upgrades easier.

### What licence does KuiklyUI use?

The repository metadata reports NOASSERTION, and the README badge links to a file named KuiklyUI License rather than a standard identifier such as Apache 2.0 or MIT. The README does not summarise the terms.

## Sources

- [Issues](https://github.com/Tencent-TDS/KuiklyUI/issues)
- [Project website](https://kuikly.tds.qq.com/home)
- [README](https://github.com/Tencent-TDS/KuiklyUI/blob/main/README.md)
- [Releases](https://github.com/Tencent-TDS/KuiklyUI/releases)
- [Tencent-TDS/KuiklyUI on GitHub](https://github.com/Tencent-TDS/KuiklyUI)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tencent-tds-kuiklyui