HarmonyOS (ArkUI)

Tier 3 · Experimental

harmony-arkui is a Tier 3 experimental target. Day uses ArkUI’s native node API with an ArkTS host project. Evaluate the controls and services your app needs before choosing it for distribution; a local compile check does not establish device or store readiness.

Getting started

This toolchain takes the most setup steps of any Day supports. You need cargo-ohos, which downloads the OpenHarmony SDK and drives the cross-compile, plus the command-line tools (hvigor, hdc, the signing tools); day doctor --toolkit harmonyos checks each piece and prints setup help, and the HarmonyOS notes cover the install in detail.

cargo install --git https://github.com/daybrite/day day-cli
cargo install --locked cargo-ohos
cargo ohos init sdk --api 18
day new app my-app --toolkit harmony-arkui
cd my-app
day build -t harmony-arkui       # cross-compiles, then hvigor → signed .hap
day launch -t harmony-arkui      # installs and starts on an emulator or device

day build signs the .hap with the public development certificate, so you get an installable artifact without a vendor account. day pack -t harmony-arkui produces the release .hap, signed with your own material when configured.

The day devices boot command starts the emulator: day devices boot -t harmony-arkui (add --headless to run without a window) boots the emulator image under QEMU and connects hdc: Oniro’s for OpenHarmony 6.x, or harmony-contrib/ohos-qemu’s x86_64_virt for 7.0, recognized by its files. It does not download images: unpack the Oniro release’s oniro_emulator.zip into ~/ohos/emulator, or point DAY_OHOS_EMULATOR at either image’s images/ directory; otherwise the command errors naming what is missing. System requirements has the download, the QEMU install, and KVM setup.

Day derives the hvigor project under build/day/harmony/project/; no checked-in build scaffold is required. day open -t harmony-arkui prepares and opens it in DevEco Studio. For custom native configuration, day project add-target harmony-arkui --persist-native-project creates an editable platform/harmony/ override. Day stages that override for builds, so edit its source files rather than the disposable project under build/.

Caveats

The widget vocabulary is implemented; platform integration is partial:

present() handles file open/save; alerts and prompts are ignored. If your UI depends on a confirmation dialog, it will silently do nothing here.
Several external pieces have no ArkUI arm: media, map, Lottie, search field, combo box, activity indicator, and remote image all render a placeholder. The date/time pickers and pull-to-refresh have native arms, and the web view has an ArkTS arm: the crate ships its own ArkTS component, staged into the host project via [package.metadata.day.ohos], with load, back/forward, stop, and reload working.
Animation (with_animation, .animation) runs on ArkUI’s own animator (animateTo): opacity, transform, and background color interpolate with the requested curve, duration, delay, and repeat, and a spring follows Day’s own spring curve. Frame changes (layout moves and resizes) apply instantly, as on Android.
All three picker styles collapse to one control: menu, segmented, and inline all become ARKUI_NODE_TEXT_PICKER.
Layout is measured for very few kinds. Labels, buttons and the text area ask ArkUI to measure; nearly everything else uses a fixed size, so unusual content may not fit as it does on other targets.
Much of the platform requires ArkTS, reached through the host project because the C API does not expose it: navigation (Navigation/NavPathStack), file pickers, opening a URL, bundled resources, custom font registration, and app bootstrap. Day wires all of this in the scaffold; you meet the ArkTS side when you go past what Day models.
Emulator behavior in CI is tolerated-flaky; the build and packaging steps gate hard.

What each piece becomes

The generated coverage matrix, checked in CI, covers every backend; this table adds links and notes.

Day calls the ArkUI native node API directly, so the mapping below is in terms of ArkUI_NodeType values. Where HarmonyOS’s NDK development guides cover a component, the node type links to that guide; the rest link to the OpenHarmony ArkUI_NodeType reference.

Day piece	ArkUI node type
`column` / `row` / `nav_stack` / `section`	`ARKUI_NODE_STACK`
`label`	`ARKUI_NODE_TEXT`
`button`	`ARKUI_NODE_BUTTON`
`toggle`	`ARKUI_NODE_TOGGLE`
`slider`	`ARKUI_NODE_SLIDER`
`text_field`	`ARKUI_NODE_TEXT_INPUT`
`secure_field`	the same field with a password input type
`text_area`	`ARKUI_NODE_TEXT_AREA`
`picker()` (all three styles)	`ARKUI_NODE_TEXT_PICKER`
`progress(f)`	`ARKUI_NODE_PROGRESS`
`spinner()`	`ARKUI_NODE_LOADING_PROGRESS`
`divider`	a 1 vp tinted `ARKUI_NODE_STACK` (no divider node type)
`scroll`	`ARKUI_NODE_SCROLL`
`list`	`ARKUI_NODE_LIST` with a node adapter (real recycling)
`tabs`	`ARKUI_NODE_SWIPER`
`nav`	`ARKUI_NODE_STACK`, with pushed pages re-homed into ArkTS `NavDestination`s
`nav_menu`	a scroll + column of row nodes
`cover()`	`ARKUI_NODE_STACK` re-homed onto the window root
`image`	`ARKUI_NODE_IMAGE`
`vector`	`ARKUI_NODE_IMAGE` rendering the staged SVG from `rawfile day/` natively
`canvas`	`ARKUI_NODE_CUSTOM` drawn with OH_Drawing
external `date_picker()`	`ARKUI_NODE_DATE_PICKER` inline, `ARKUI_NODE_CALENDAR_PICKER` compact
external `time_picker()`	`ARKUI_NODE_TIME_PICKER`
external `pull_refresh()`	`ARKUI_NODE_REFRESH`
external `webview()`	the ArkTS `Web` component: the piece’s ArkTS, staged via `[package.metadata.day.ohos]` (the C node API has no Web node)

Further reading in the HarmonyOS NDK guides: using NDK APIs to build UIs (the index), NDK-based UI development overview, integrating with ArkTS pages (the ArkTS bridge Day’s scaffold wires), adding event responses, and building form components. The ArkUI_NodeType reference in the OpenHarmony documentation enumerates every node type, including the ones the guides don’t cover.