A general-purpose agent writing ArkTS will crash and burn, for exactly three reasons. It does not know ArkTS decorators or build commands; it has no official docs to look things up in, so it invents APIs from memory; and even when the code is right, it has no idea how to build the package, install it on a device, and ship it to the app store.

The holes can be plugged one at a time. Huawei and the community turned the plugging into tools you can bolt on externally, and going from nothing to usable is eight steps. This post walks them in order, with the command for each step and the output you should expect. At the end I wire all three pieces into a real agent, DeepSeek Harness, to see whether it actually buys it.

Four things to install

DevEco Studio, or its command line tools, is the foundation. Building, devices, signing, all the real work sits on it. @deveco/deveco-cli is the toolset, command name devecocli, and its job is installing capabilities into other agents.

The two MCPs do different jobs. The remote developer knowledge MCP handles doc lookup. The local deveco-mcp handles syntax checking for .ets and C/C++. The last piece is agc-cli, a community-written publishing CLI that drags AGC console operations back into the terminal.

Also get a Huawei developer account ready first. Installing the foundation and generating signatures both need it.

Step one: install the foundation

Go to the developer alliance download center (developer.huawei.com/consumer/cn/download/), log in, and pick the macOS build. On Apple Silicon you want the macOS ARM one.

Note the path after install. The default is /Applications/DevEco-Studio.app. You cannot skip this step, every real job devecocli does later depends on it.

If you do not want the whole IDE, the other path is the command line tools on the same page. Much smaller, but the official docs call one thing out:

Set DEVECO_CLI_CLT_PATH to the Command Line Tools root when DevEco Studio is not installed; CLT is not discovered automatically from PATH or default installation directories.

It will not be discovered from PATH or the default directory on its own. You have to point an environment variable at it by hand:

# IDE installed
export DEVECO_CLI_STUDIO_PATH=/Applications/DevEco-Studio.app
# command line tools only
export DEVECO_CLI_CLT_PATH=$HOME/command-line-tools

Put those in ~/.zshrc to make them stick. On first launch Studio walks you through downloading the HarmonyOS SDK. That needs network and it is slow, so do not sit there waiting somewhere offline.

Step two: install the devecocli toolset

Two npm packages together:

npm install -g @deveco/deveco-cli @deveco/deveco-code

You get two commands. deveco is the Agent itself, customized from OpenCode; devecocli is the toolset. 255 dependencies between the two packages, 267 MB.

Check it before moving on:

devecocli --help
devecocli device list

The second one lists connected devices. If it says DevEco Studio cannot be found, the problem is not this command, go back and check that environment variable from step one.

Step three: install the skill pack into your agent

This is the answer to the any agent half, one command:

devecocli init --skill --agent dsh,cursor,codex

Without –agent it installs into every host it recognizes. To install into a specific directory use –path, and add -f to overwrite existing config.

What lands looks like this:

node_modules/@deveco/deveco-cli-common/SKILL.md

24,690 bytes, and the trigger conditions at the top are blunt:

Use ‘devecocli’ for HarmonyOS apps (scaffold, build, run, debug, devices, emulators, logs, docs, UI inspection, 鸿蒙开发文档, skills). Use it if workspace has build-profile.json5 or oh-package.json5, or user mentions HarmonyOS, 鸿蒙, DevEco, ArkTS, ArkUI …

Once the agent reads that, hitting a HarmonyOS project or hearing the word HarmonyOS makes it think of devecocli on its own. The same package also carries an offline doc corpus. docs.zip is 40.5 MB, unpacking to 31,477 files, plus a 15.2 MB search index. That is what devecocli docs search queries, and it works without network.

Supported hosts are the official list: atomcode, codebuddy, claude-code, codex, cursor, dsh, deveco, opencode, pi, qoder, trae-cn. Eleven of them. For hosts outside the list there is a crude workaround: a skill pack is ultimately one Markdown file plus a doc corpus, so dropping it into that host’s skill directory is the same thing.

To install in bulk or see what is already installed, use the skills subcommand:

devecocli skills list
devecocli skills add --all

Step four: install the local syntax-check MCP

devecocli init --mcp

It configures deveco-mcp, a stdio MCP that exposes a single check tool, dedicated to syntax checking .ets, C and C++. Once it is wired into the agent, every round of edits gets self-checked before the agent moves on, instead of waiting for a full build to fail. The docs add one note: run it once per round of edits, not after every single edit.

One limitation from the docs: every supported host can configure global and project-level MCP, only qoder does not support project-level.

The service can be started by hand, which is useful when debugging:

devecocli serve mcp

It honors a few environment variables: PROJECT_PATH, DEVECO_PATH, and NODE_MAX_OLD_SPACE_SIZE for the Node heap cap.

Step five: connect the official knowledge MCP

This is the most universal piece. Any client that supports MCP just gets a block in its config:

{
  "mcpServers": {
    "harmonyos_developer_knowledge": {
      "url": "https://connect-api.cloud.huawei.com/api/developerknowledge/mcp",
      "type": "http"
    }
  }
}

DevEco Code ships its own MCP management command, one line:

deveco mcp add harmonyos_developer_knowledge \
  --url https://connect-api.cloud.huawei.com/api/developerknowledge/mcp

It reports status itself when done:

●  ✓ harmonyos_developer_knowledge connected

It only has two tools. searchDocuments searches by keyword and returns matching text blocks plus document IDs; getDocumentsById trades IDs for full text, ten documents max per call. Know the cost: about three thousand characters per search, thirty-five thousand per full document. Do not let it pull ten at once. The docs say this corpus syncs with the official site near real time, under 30 minutes of lag, and that is the most important difference between this path and letting the model answer from memory.

DeepSeek Harness as the example: how three pieces land in a real agent

The steps above covered what to do. This section runs through dsh to show where it lands. It happens to be on that official host list, so all three pieces connect automatically.

The skill pack is one command, landing in dsh’s own skills directory:

devecocli init --skill --agent dsh
ls ~/.dsh/skills

The directory structure is identical to its existing skills. One directory, one SKILL.md, two frontmatter lines at the top for name and description. This machine’s ~/.dsh/skills already had seven skills starting with memorix-, and deveco-cli now sits alongside them.

MCP goes into dsh’s config file cordis.patch.yml. Its config is layered profile patches, and MCP runs through its own mcp-client plugin, one record per service. The knowledge MCP goes in like this:

- insert:
    - id: mcp-harmonyos-knowledge
      name: "@deepseek-ai/dsh-mcp-client"
      config:
        serverName: harmonyos_developer_knowledge
        transport: streamable-http
        url: https://connect-api.cloud.huawei.com/api/developerknowledge/mcp

The local syntax-check MCP only swaps transport and the start command:

    - id: mcp-deveco-syntax
      name: "@deepseek-ai/dsh-mcp-client"
      config:
        serverName: deveco
        transport: stdio
        command: devecocli
        args: [serve, mcp]

It only recognizes two transports. stdio is a locally started process, streamable-http is a server. A few defaults worth knowing: 60 second timeout per tool call, 32,768 bytes cap on instructions from the server, and auto-reconnect on disconnect, up to ten attempts.

After editing, do not restart and guess. dsh has a dump command that prints the whole merged config:

dsh --profile <your profile> --patch ./hw-mcp.yml --dump-config

Once the config merges into the profile tree, the tool names really do show up in its tool table. I ran this with an isolated DSH_HOME:

mcp__harmonyos_developer_knowledge__searchDocuments
mcp__harmonyos_developer_knowledge__getDocumentsById

The naming rule is mcp, two underscores, service name, tool name, so several MCPs in the same agent will not collide. At this point, ask how to write a HarmonyOS interface inside dsh and it goes to the official docs instead of inventing something from memory.

Step six: login and signing

To run on a real device you cannot skip this.

devecocli auth login

It opens a browser for the Huawei developer account OAuth flow. Check login state with devecocli auth status, list joined team accounts with devecocli auth team list. Then generate a signature:

devecocli signature generate --product default

The order is spelled out clearly: auth login, signature generate, build, run. Not one step can be skipped. Each missing step has its error: not logged in gives Not logged in. Run devecocli auth login first, an expired token gives Invalid AccessToken. Sign in and try again, a changed signature gives error:install sign info inconsistent, at which point add –uninstall to run, or –force when regenerating the signature.

Step seven: install agc-cli

Publishing goes through AGC, which used to mean clicking through pages in a browser. This open source CLI turns the API into a searchable registry. In my test it had 159 endpoints across 13 families, each with method, path, required parameters, and a sourceUrl pointing back to Huawei’s official docs.

The Homebrew route needs you to trust its tap first:

brew tap createitv/tap
brew trust createitv/tap
brew install agc-cli

Or download the prebuilt binary from the official Release. There is a darwin_arm64 package, so verify the hash before using it:

shasum -a 256 agc-cli_0.2.0_darwin_arm64.tar.gz
./agc version

Three ways to configure credentials, pick one:

agc auth login --client-id <id> --client-key <key>
agc auth login --api-client-file client.json
agc auth login --service-account-file sa.json

agc auth check shows which one is active, agc auth list lists all stored profiles, agc auth token signs a temporary token for the current one.

By default it only rehearses. Before anything really goes out you see what the request looks like:

agc publishing app-info-query --invoke --query appId=123456789
{"data":{"method":"GET","url":"https://connect-api.cloud.huawei.com/api/publish/v2/app-info?appId=123456789&lang=zh-CN","dryRun":true}}

Once you are happy, explicitly add –dry-run=false to actually send it. Each endpoint’s response also carries an affordances block listing which command you can run next. The agent does not need to memorize the command tree, it just follows the response.

Step eight: run it and watch the agent check its own work

With all this installed, project to device is a straight line:

devecocli build
devecocli emulator list
devecocli emulator start "Phone"
devecocli run

The first emulator use needs a license, interactive with devecocli emulator license, which requires a TTY, or devecocli emulator license accept in scripts. If the image download fails, do not retry in a loop. The docs say plainly to hand that one to the user.

After the run, look at the two directories that appeared in the project. .verify holds verification artifacts, docs/screenshots holds screenshots, and the latter were produced automatically:

docs/screenshots
  01-home.png                          home
  03-quick-entry.png                   quick entry
  05-stats-mpchart.png                 stats charts
  06-stats-retry.png                   retry after stats failure
  08-trip-edit.png                     trip editing
  09-home-empty.png                    empty state
  10-real-device-home.png              real device
  11-real-device-trip-detail-finish.png
  12-light-home.png                    light theme
  15-dark-home.png                     dark theme
  19-dark-to-system-fixed.png

Numbers run from 01 to 19. Two of them are real device screenshots, meaning it installed the package on a device and actually ran it. Light and dark each get a set, meaning theme switching is in its flow too. There are empty states and the retry state after a stats failure, meaning it is not satisfied with the happy path and lays out the corner cases one by one. None of these were taken by hand.

The point of this step is the loop closing. Before, the agent handed you code and you had to look at whether it was any good. Now it can see the result itself, screenshots land as files, and the next round of edits has something to go on. This is also why I would file devecocli under tool rather than client: it is not the hand that writes code for you, it is the eye that lets the agent check its own work.

One verification command per step

Do not go by feel afterwards, walk through them one by one:

devecocli --help                  # toolset is there
devecocli device list             # devices are found
devecocli docs search ArkTS       # offline docs are there
devecocli skills list             # skill pack installed
deveco mcp list                   # knowledge MCP connected
devecocli auth status             # login state
agc auth check                    # AGC credentials configured
agc endpoints                     # registry readable

Whichever one fails, the problem is in that step, and you do not have to hunt around.

A bit of judgment

Of the four things, which would I install first? The foundation, because everything else is blocked on it. But if you only want to spend twenty minutes testing the water, connect the remote knowledge MCP first: one URL, no device, no account, and it plugs the most fatal hole.

Do not reverse the order. The skill pack and local MCP both hang off devecocli, and devecocli’s real work hangs off DevEco Studio. With a weak foundation, every later step hits the same sentence.

Do you let your everyday agent write HarmonyOS code? Where does it crash most often? Tell me in the comments.

A while back I wrote a piece on HarmonyOS and KMP, and at the time I found one key fact: the stable release the community published was HarmonyOS support built on KMP 2.2.21 / CMP 1.9.2.

Going back to that repo the other day, I found one extra line in the branch list:

develop-2.4 Documentation set for framework KMP 2.4.21 _ CMP 1.12.0

And the branch was updated 21 hours ago.

There is another one:

main-2.2 (default branch) Documentation set for framework KMP 2.2.21 _ CMP 1.9.2

On one side, the stable release already shipped. On the other, the new baseline being pushed forward.

On the HarmonyOS front, KMP is starting to line up with the latest upstream version.

And at almost the same moment, upstream JetBrains had just released Kotlin 2.4.20.

Two tracks, colliding at one point in time.

First, the upstream track: what changed in Kotlin 2.4.20

If you only skim the changelog you might think, oh, another patch-and-polish release — of the two hundred-odd changes, most are bugfixes.

But a few of them land hard for people who write KMP.

One: Swift interop can finally hold its own.

Swift export now supports mapping Kotlin’s sealed class straight to a Swift enum:

// no more default
let name = switch shape.sealedType() {
case .circle(let t):    "圆"
case .rectangle(let t): "方"
}   // ← exhaustiveness check

Handling this kind of polymorphic type used to mean either a pile of if let on the Swift side, or being forced to add a default branch that can never run — which kills exhaustiveness checking outright. Now the compiler catches the gaps for you.

There is also cross-language inheritance: a Kotlin type can inherit from a Swift class or protocol (including pure Swift libraries), with no wrapper layer needed.

Both point the same direction: the interop friction KMP has always been criticized for on iOS is being sanded down, bit by bit.

Two: klib incremental compilation hits Beta.

kotlin.incremental.native=true

Change one line of Kotlin and you no longer wait for the whole native module to rebuild. If you have done Kotlin/Native, you know what that does for the day-to-day.

Three: the Kotlin/JS test toolchain moved from Karma to Playwright — about time.

So the theme of the upstream track is: smoothing out the seams between languages.

Now the HarmonyOS track: where it actually stands

To understand the HarmonyOS side you have to start with its version numbering scheme, written in the stable release announcement that went out yesterday:

Version numbers use “upstream baseline + HarmonyOS adaptation sequence”: 2.2.21-1.0.0 / 1.9.2-1.0.0 means a HarmonyOS adaptation stable release based on upstream KMP 2.2.21 and CMP 1.9.2.

That rule matters. It says one thing:

HarmonyOS support is not a separate stove. It is chasing upstream versions.

Which is why you see numbers like 2.2.21-1.0.0 — the 2.2.21 in front is the upstream Kotlin version it corresponds to, and the 1.0.0 behind is the HarmonyOS adaptation’s own iteration number.

Already published to Maven:

And the new develop-2.4 branch targets a baseline of KMP 2.4.21 / CMP 1.12.0.

The development cadence announcement says it too:

develop branch: used for monthly development-state code merges, merged into main after each monthly release gate.

In plain language: one version forward every month, merged into the stable line only once it is ready. Not shipping on a whim, but a rolling cadence.

What that branch has been busy with

I went through the develop-2.4 commit history. The recent activity is interesting.

The latest one adapts the CAPI user manual to API 26 — bumping the OHOS CAPI version to API26, updating “modules, minimum API, and typical dependency libraries” to match, and adding a whole section on “special changes caused by the CAPI upgrade to API 26.”

Another one updates akinterop to 1.0.1 and sqldelight to 2.2.1-1.1.0.

Those two directions map exactly to the two real blockers for HarmonyOS cross-platform work:

• CAPI follows the HarmonyOS system version — the system upgrades, the bridge layer has to upgrade with it. That is the “do not fall behind” problem
• Adapted version numbers for third-party libraries — whether the ecosystem libraries keep up decides whether a project dares to use this at all

While we are here: what CMP 1.12 brings upstream

Since develop-2.4 is tracking CMP 1.12.0, what changed in 1.12 upstream is worth a look too.

CMP 1.12.0 shipped on August 25, and the highlight is on the Desktop side:

MCP server was introduced for Compose Hot Reload that enables AI agents to interact with a running Compose application in real time

In plain language: Compose hot reload got an MCP server, so an AI agent can interact with a running Compose app in real time.

That one is subtle. The intersection of Compose and AI is moving from “use AI to write Compose code” toward “let AI operate the running app directly.”

It also brings a batch of breaking changes, so watch out when migrating:

• The deprecation level on typealiases like NativeCanvas and NativePaint was raised to ERROR
• The background parameter on SwingPanel is deprecated

Jumping from 1.9.2 to 1.12.0 is not just a version number change — migration cost counts too.

What the two things together tell you

Put the two tracks side by side and the picture is fairly clear:

KMP’s “one codebase, many platforms” is being pushed forward on several fronts at once.

• Upstream is polishing cross-language interop (Swift export, incremental compilation)
• The HarmonyOS community track is chasing upstream versions (2.2 → 2.4), filling in system support (CAPI → API 26), and widening the third-party library ecosystem

They are not the same team, but they are heading in the same direction — making “write Kotlin once, run on more platforms” a little less friction.

For developers, the test is simple:

When you evaluate a new platform, the question is no longer “does it support this” but “which upstream version has it caught up to, are the libraries enough, does the performance hold up.”

From “can it run” to “can it keep up” — that shift is itself a new stage.

But the community’s real voice is worth more than the announcement

Announcements are always pretty. I went and read the community discussion forum on purpose, because that is where this track’s actual temperature is.

The hottest thread asks “can this be merged into the official JetBrains branch soon” (started 30 days ago, 7 replies).

The poster was direct:

Adding HarmonyOS to my existing pure KMP & CMP app project runs into a large number of unsupported libraries, and during compilation several already-adapted libraries show internal dependency conflicts. I hope it can be merged upstream soon so library developers across the whole KMP community can add ohos versions, the CPF community’s progress on library support is far too slow.

He named three libraries specifically: androidx-datastore, androidx-room3, androidx-sqlite — “these three are basically the foundational dependency libraries for the persistence approaches everyone uses.”

Then the part that stings:

None of them support ohos x86. On Windows a developer can barely build and test an app with normal functionality — at minimum you have to keep a HarmonyOS phone plugged in as the test target…

He also gave a concrete trap: a room3 alpha pulled from some mirror repo generates code that errors on a missing androidx.sqlite implementation, while upstream room3 3.0.1 works fine.

The official reply came, and it was honest:

Hello, support for ohos x86 is already in planning, thanks for your interest.

Other threads are each real in their own way:

• “Under skia rendering the page frame production is dragged to about one frame per 3 seconds, suspected abnormality in the VsyncOnDemand deferred deregistration mechanism” — performance
• “material3 blocks porting an existing project” — component library traps
• “Is webView supported right now?” — capability coverage
• “Has anyone actually shipped a project? What traps did you hit” — and someone replied with: “currently doing a KMP adaptation of a voice assistant”

Add these up and you have the real state of this track: it runs, people are using it, but the ecosystem and performance are still catching up.

Why “following upstream” is slow work

Seeing that “progress is far too slow” line, some people will assume it is a matter of insufficient investment.

But there is a technical reality worth spelling out: HarmonyOS support changes the compiler backend. It is not writing a plugin.

Go through the CPF-KMP-CMP repo list and you see these names:

kotlin, compose-multiplatform, compose-multiplatform-core, skiko, akinterop, cicd-toolkit…

These are HarmonyOS forks of the Kotlin compiler, the Compose framework, and the graphics rendering layer.

Which means the work includes at least:

• Adding a new compilation target to Kotlin/Native
• Wiring Compose’s rendering pipeline into HarmonyOS’s Render Service
• Getting the Skia graphics library that Skiko wraps to run on HarmonyOS

And every time upstream ships a new version, all of those changes have to be re-aligned.

That is what the “upstream baseline + adaptation sequence” version scheme really means — it describes the nature of the work precisely: continuous tracking, not a one-time port.

Look again at “monthly development-state merges, merged into main after each monthly release gate” and it reads differently:

This is not slow. This is doing a very heavy thing at a pace that can be sustained.

A few of my own views

One: the essence of “adaptation” here is following upstream, not reinventing the wheel.

You can see it in the version scheme alone (upstream baseline + adaptation sequence). The core work on the HarmonyOS track is getting upstream’s compiler and UI framework running on HarmonyOS, not inventing a separate API.

Which means its ceiling is tied to upstream: upstream smooths out Swift interop and that is a dividend for iOS; upstream improves the compiler and HarmonyOS only gets it by keeping up.

Two: the three community complaints point at the same problem.

x86 support, third-party library versions, performance — three things on the surface, all “ecosystem maturity” underneath.

And ecosystem maturity has a cruel property: it cannot be solved with enthusiasm, only with time and real projects wearing it in. The official reply of “already in planning” is true, and there is a certain helplessness in how true it is.

Three: if you are evaluating whether to get on this track, here is a framework.

Do not ask “does it support HarmonyOS” — ask these three questions:

1. Which upstream version has it caught up to? (right now 2.2.21 is stable, 2.4.21 is in development)
2. Have the libraries I depend on been adapted? (especially foundational ones like persistence and networking — room3 and datastore are the acknowledged pain points)
3. What is my dev machine? (if you need an x86 emulator, you still have to wait; an Apple silicon Mac plus a real device is the steadier combination)

All three clear, then start. One blocked, and the plan goes in a note for later.

Last

Kotlin 2.4 and HarmonyOS 2.4 look like two unrelated things.

But they are answering the same question:

One body of Kotlin code: how many places can it run, and how well?

Upstream is sanding down the seams between languages, and the HarmonyOS track is widening the map.

Both are making that number bigger.

I want to ask you something:

Would “HarmonyOS support has caught up to 2.4” make you reconsider a KMP project you have on your desk?

Or have you already been through the traps on this track? Talk in the comments — I would genuinely like to hear from real projects.

References: CPF-KMP-CMP community repos (AtomGit/GitCode) branch and release announcements, public posts in the community discussion forum, JetBrains Kotlin 2.4.20 release notes.

Start with a number: four.

Android, iOS, desktop — that’s the main ground Kotlin Multiplatform has covered steadily for years (Web / Wasm is still in progress). Write one set of shared logic, add one Compose UI, and several platforms run together.

And yesterday, that list gained a fourth member: HarmonyOS.

And this time it isn’t “theoretically runs” — it’s an official release. Components are in the Maven repo, the toolchain plugin is searchable in the Android Studio plugin marketplace, and the docs are on AtomGit.

What surprised me most was the publisher’s line:

Teams already using CMP on other platforms can reuse the same Compose code for UI and business logic directly, without writing a whole separate ArkUI implementation for HarmonyOS.

No ArkUI rewrite. For anyone doing cross-platform, those few words carry real weight.

Let’s get the facts straight

What shipped is the first HarmonyOS release of KMP&CMP, on September 15, 2026.

The key facts:

• Who made it: built jointly by community partners in the CPF-KMP-CMP SIG (note: a community SIG, not JetBrains official — I’ll get into that distinction later)
• Based on: upstream KMP 2.2.21 / CMP 1.9.2
• Goal: bring the “shared logic, native UI rendering” paradigm to HarmonyOS
• How to get it: components are published to the Maven repo; the toolchain plugin KMP OHOS Support is searchable and installable from the Android Studio plugin marketplace

The official positioning on who it’s for is clear too:

For teams already using KMP/CMP for cross-platform work, this release helps lower the cost of moving to HarmonyOS. HarmonyOS teams can also use it for mixed Kotlin and ArkTS development, and to widen their technology options.

Translated: KMP teams who want HarmonyOS now face a lower cost; HarmonyOS teams who want Kotlin now have a path.

Some background while we’re here — this has been building for three months. The community edition opened Beta in June, and in August InfoQ reported a round of measurements (95% less rendering memory, 90% fewer GC jank incidents). Now it’s properly landed.

Highlight one: Compose runs on HarmonyOS directly, no UI rewrite

This is the one I think is most valuable.

On HarmonyOS, the official route is ArkTS + ArkUI. For a team already doing KMP/CMP, that means the HarmonyOS side needs its own separate UI — business logic shared, but the interface rewritten.

This release paves that road:

CPF-KMP-CMP provides platform implementations of compose.ui, compose.foundation, compose.material and compose.material3 on the HarmonyOS side, so you can keep the familiar declarative UI habits while building HarmonyOS screens.

compose.material3 is there. Which is to say, the Compose code you’re used to writing is recognized on HarmonyOS.

For a project already running CMP on Android/iOS, that means the cost of adding HarmonyOS drops from “rewrite a UI” to “add a target”.

How big a difference is that? Anyone who’s done cross-platform knows.

Highlight two: Kotlin ↔ ArkTS two-way interop

The second one matters a lot for existing projects.

The reality is: plenty of HarmonyOS projects already have a pile of ArkTS (system capabilities, business modules), and ripping it all out for Kotlin isn’t an option.

The answer here is akinterop:

Shared logic can keep being written in Kotlin. When the system side or existing modules stay in ArkTS, use akinterop for two-way interop: declare intent with annotations / decorators, let the toolchain generate the bridge, and write less C glue. Primitive types, containers and exceptions can cross sides, existing projects can adopt incrementally, and nothing has to be torn down for interop.

“Adopt incrementally, nothing torn down” — that line is the reassurance existing projects needed.

Annotation declares intent, toolchain generates the bridge — a far better experience than hand-writing C glue. Anyone who’s written JNI knows that pain.

Highlight three: unified rendering (this is the technical core)

This one’s more hardcore, but I think it’s the most technically substantial piece of the whole thing.

The problem first: traditional cross-platform UI approaches usually build their own rendering pipeline.

What’s wrong with building your own? The report says it directly:

Traditional cross-platform UI solutions often build their own rendering pipeline, which tends to add initialization and composition overhead, and often shows up as slow startup and animations that don’t match the system.

Self-rendering means your UI doesn’t go down the system’s path — startup needs an extra init step, animation rhythm doesn’t line up with the system, and it just looks “not native”.

This approach goes the other way:

CPF-KMP-CMP connects Compose’s drawing capability to HarmonyOS’s Render Service / RenderNode system rendering, with HarmonyOS handling composition and refresh scheduling uniformly (unified rendering requires API 19 or above).

Handing drawing over to HarmonyOS to composite itself pays off in a chain:

• Faster first frame: no self-rendering init wait, so startup and navigation feel snappier
• Fine-grained partial refresh: update only when state changes, with partial recording support — only the changed region is repainted
• Native component mixing: Compose screens can mix with ArkUI and C-API, so native capabilities like maps and video are easier to embed
• System-aligned animation: frame rhythm follows the system’s DisplaySync, so animation matches native HarmonyOS apps

That last one matters especially. The reason cross-platform apps look fake at a glance often isn’t wrong layout — it’s that the animation rhythm is wrong, frame scheduling off the system’s beat.

⚠️ Note one limitation: unified rendering requires API 19 or above. On older devices it degrades.

The performance account: 20% off compile time, 30% off heap

They gave some genuinely specific numbers this time, unlike the vague claims that usually pass for “performance optimization”:

Compile side (parallel compilation):

Splitting LLVM IR and running local optimization across threads before merging shortens compile waits on large projects; typical scenarios save roughly 20%+ of the time.

Memory side (CommonGC):

Using a concurrent mark-copy collection algorithm to reduce memory fragmentation and GC pause time, KN heap usage in typical scenarios drops by about 30%.

There are also two engineering optimizations that are genuinely practical:

• Modular splitting: a single KMP project can be configured into multiple .so files, and combined with distributed compilation it shortens builds further
• Debug incremental compilation: on macOS / Linux, incremental compilation based on a static library cache — only the changed part recompiles, no full relink every time

(Anyone doing KMP probably has a small stress reaction to the words “full relink”)

One more detail I like — no idle spinning in the background:

The unified rendering path supports requesting VSync signals on demand, actively suppressing refresh drawing when page content hasn’t changed; it also supports LTPO hardware characteristics, stopping pointless draw loops automatically once the app goes to the background… This is framework default behavior, requiring no extra code from the app.

Default behavior, no app code needed. This kind of “the framework worries about it for you” design is far friendlier than making you turn animations off by hand in onPause.

Getting started: three steps

The flow is simpler than I expected:

(1) DevEco Studio: use 6.0.0+ to download HarmonyOS SDK API 17+, open the harmonyApp in the project and set up the debug signature. (2) Android Studio: write KMP&CMP code day to day. (3) Android Studio: pick a device and harmonyApp, hit Run (keep DevEco running while pushing the package).

Note the parenthesis in step 3 — DevEco Studio has to stay open while pushing. That kind of “two IDEs cooperating” detail is exactly where people trip, and they said it up front.

The docs are on AtomGit (search CPF-KMP-CMP/docs) if you want to dig in.

Why this piece of the HarmonyOS puzzle matters so much

Honestly: for KMP developers in China, this puzzle piece may matter far more than Web/Wasm.

The reason is practical — for mobile work in China, HarmonyOS is no longer a “should we consider it” question, it’s a “when do we have to” question. Especially in government and enterprise, finance, automotive and IoT, where it’s moving faster than many expected.

And the choice KMP teams faced with HarmonyOS used to be awkward:

• Shared logic carries over, but the UI gets rewritten (ArkUI) → which means an extra person on the HarmonyOS side
• Or drop KMP entirely and start a separate HarmonyOS project → all the shared-logic advantage gone

The point of this release is right there: it takes most of the “HarmonyOS UI has to be rewritten too” cost out of the equation.

For a small team, that may be the difference between “can’t afford it” and “can afford it”.

A cooler read: how to see this

Hype is hype. I need to be clear about a few boundaries so you don’t misjudge.

First, this is a community SIG project, not JetBrains official.

The publisher is the CPF-KMP-CMP SIG, not JetBrains and not an official Huawei release. That doesn’t make it bad — quite the opposite, this kind of “ecosystem foundation” usually gets chewed through by community SIGs bit by bit — but set your expectations accordingly:

• Long-term maintenance depends on community activity, without the explicit commitments an official API carries
• When you hit a problem, the answer is in the community (issues, discussions), not in official docs

Second, unified rendering needs API 19+.

If your target devices include a lot of older HarmonyOS builds, you don’t get that biggest performance dividend, so assess your device distribution.

Third, it solves a real problem.

Cross-platform on HarmonyOS used to offer basically two options:

• Write ArkUI separately for HarmonyOS, maintaining two UIs
• Skip HarmonyOS, wait for official support

Now there’s a third: keep writing shared logic, reuse the Compose UI, bridge existing ArkTS with akinterop.

For a team that’s already invested in KMP, the cost-benefit of that third road is hard to ignore.

Put it back in the arc of the last few days

Funny thing: this lines up with two topics from the last couple of days into one thread.

In the Jake Wharton piece, he puts it clearly:

Knowing Kotlin is no longer a career advantage… but having something more advanced like Kotlin Multiplatform can still be a differentiator.

The Shopify piece concludes: once AI makes “reimplementing it” cheap, the “share the UI” camp takes the biggest hit, while “shared logic + native UI” holds up better.

And then today: KMP’s map just gained another region — and a big one.

Three things point the same way: the value of cross-platform is shifting from “save headcount” to “architecture governance + ecosystem coverage”.

Chewing through platforms one at a time was always the core story of the KMP bet. With the HarmonyOS piece filled in, for developers in China especially — it may be the first time many of them have a real reason to look at KMP seriously.

One question to leave you with:

If you can write HarmonyOS UI in Compose, would you still maintain a separate ArkUI codebase for it, or just extend your KMP project to HarmonyOS?

And — for the project in your hands, is HarmonyOS a “must do” or a “let’s see”?

Comments are open, I really want to know where people actually are.

References:

• First official HarmonyOS release of KMP&CMP (Kuai Technology / Drive Home, 2026-09-15)
• Docs: search CPF-KMP-CMP/docs on AtomGit