How ArkUI‑X Bridges ArkTS to Android and iOS: A Deep Dive

Introduction

Today’s mobile cross‑platform landscape includes Flutter, React Native, uni‑app and the newly released Compose‑Multiplatform. Each framework has its own rendering strategy; for example, Flutter uses Dart UI descriptions compiled to a custom engine, while React Native relies on JavaScript to generate native UI components. This article introduces a newer framework, ArkUI‑X , and explores its architecture.

ArkTS, ArkUI, ArkUI‑X

Before diving into ArkUI‑X, it is useful to understand the three related concepts:

ArkTS – Huawei’s TypeScript‑based language for HarmonyOS application development. It adds static typing to improve performance.

ArkUI – A declarative UI framework that provides components (Text, Image), state management (State, LocalStorage), layout and event handling.

ArkUI‑X – Extends ArkUI to multiple operating systems, currently supporting OpenHarmony, HarmonyOS, Android and iOS, with more platforms planned.

Developers write UI with ArkUI and code with ArkTS, then use ArkUI‑X to adapt the same source to Android and iOS.

Quick Start

1. Environment setup

Install DevEco Studio (version 4.0.0 or later) and add HarmonyOS SDK and ArkUI‑X. Non‑partner developers should download the OpenHarmony SDK.

Install Android Studio for Android APK generation.

Install Xcode for iOS IPA generation.

Download the example projects:

Creating a Project

After the environment is ready, create a new project using the ArkUI‑X template. The generated project structure looks like this:

entry – Contains the application entry, core business logic and shared resources. This mirrors the standard HarmonyOS project layout.

.arkui‑x/android – A standard Android project (incomplete until the app is built).

.arkui‑x/iOS – A standard iOS project with project.pbxproj.

Running Build App/Hap produces a .hap package for HarmonyOS and, after packaging, .apk for Android and .ipa for iOS. The build process injects the shared ArkTS code and resources into each platform’s output.

ArkUI‑X also provides a command‑line tool called ACE Tools for the same workflow (see the ACE Tools quick guide).

Inspecting the Rendering Process

Consider the following simple demo ( Index.ets) written in ArkTS:

// Index.ets
@Entry
@Component
struct Index {
  @State message: string = '今天星期五'

  build() {
    Row() {
      Column() {
        Text(this.message)
          .fontSize(50)
          .fontWeight(FontWeight.Bold)
      }.width('100%')
    }.height('100%')
  }
}

After building, the compiler generates a JavaScript class that extends ViewPU:

class Index extends ViewPU {
  constructor(parent, params, __localStorage, elmtId = -1, paramsLambda = undefined, extraInfo) {
    super(parent, __localStorage, elmtId, extraInfo);
    this.__message = new ObservedPropertySimplePU('今天星期五', this, "message");
    this.setInitiallyProvidedValue(params);
  }
  setInitiallyProvidedValue(params) {
    if (params.message !== undefined) {
      this.message = params.message;
    }
  }
  aboutToBeDeleted() {
    this.__message.aboutToBeDeleted();
    SubscriberManager.Get().delete(this.id__());
  }
  private __message: ObservedPropertySimplePU<string>;
  initialRender() {
    // UI description generated by the compiler
    this.observeComponentCreation2((elmtId, isInitialRender) => { Row.create(); Row.height('100%'); }, Row);
    this.observeComponentCreation2((elmtId, isInitialRender) => { Column.create(); Column.width('100%'); }, Column);
    this.observeComponentCreation2((elmtId, isInitialRender) => { Text.create(this.message); Text.fontSize(50); Text.fontWeight(FontWeight.Bold); }, Text);
    Text.pop(); Column.pop(); Row.pop();
  }
}

The generated class inherits from ViewPU, which itself extends PUV2ViewBase → NativeViewPartialUpdate. The ViewPU implementation lives in the arkui_ace_engine repository and handles state subscription, partial updates, and interaction with the native rendering engine (OpenGL ES/Skia).

Android Implementation Details

When the app is built for Android, the compiled modules.abc bytecode and related resources are copied into src/main/assets/arkui‑x:

src/main/assets/arkui-x
├── entry
│   ├── ets
│   │   ├── modules.abc
│   │   └── sourceMaps.map
│   ├── resources.index
│   ├── resources
│   └── module.json
└── systemres

Native libraries required for rendering are placed under libs:

libs
├── armabi‑v7a
│   ├── libarkui_android.so
│   └── libhilog.so
└── arkui_android_adapter.jar

libarkui_android.so

bundles arkui_ace_engine, arkui_napi, foundation/appframework and other components. The arkui_android_adapter.jar provides Java bridge classes such as StageApplication and StageActivity, which map Android Activity lifecycles to HarmonyOS Ability lifecycles and expose system capabilities (clipboard, keyboard, storage, logging, etc.).

The interaction chain from ArkTS to Android system APIs is:

ArkTS → NAPI → C++ → JNI → Java

Developers do not need to manage this chain; the framework abstracts it away.

Clipboard Example

The following ArkTS snippet copies text to the system clipboard:

import pasteboard from '@ohos.pasteboard';
Button('拷贝到粘贴板')
  .onClick(() => {
    let pasteData = pasteboard.createData(pasteboard.MIMETYPE_TEXT_PLAIN, '明天星期六');
    let systemPasteboard = pasteboard.getSystemPasteboard();
    systemPasteboard.setData(pasteData);
  });

On Android, the abstract Clipboard interface defined in

arkui_ace_engine/frameworks/core/common/clipboard/clipboard.h

is implemented by ClipboardImpl in arkui_for_android. The implementation forwards the call to ClipboardJni::SetData, which registers a native method via JNI and finally invokes ClipboardManager#setPrimaryClip in Java:

// ClipboardImpl::SetData (C++)
void ClipboardImpl::SetData(const std::string &data, CopyOptions copyOption = CopyOptions::InApp, bool isDragData = false) override {
    taskExecutor_->PostTask([data] { ClipboardJni::SetData(data); }, TaskExecutor::TaskType::PLATFORM, "ArkUI‑XClipboardImplSetData");
}

// JNI registration (C++)
static const char CLIPBOARD_PLUGIN_CLASS_NAME[] = "ohos/ace/adapter/capability/clipboard/ClipboardPluginBase";
static JNINativeMethod METHODS[] = { { .name = "nativeInit", .signature = "()V", .fnPtr = reinterpret_cast<void*>(ClipboardJni::NativeInit) } };

bool ClipboardJni::SetData(const std::string &data) {
    auto env = JniEnvironment::GetInstance().GetJniEnv();
    jstring jData = env->NewStringUTF(data.c_str());
    env->CallVoidMethod(g_clipboardObj.get(), g_pluginMethods.setData, jData);
    if (jData != nullptr) env->DeleteLocalRef(jData);
    return true;
}

// Java side (arkui_android_adapter.jar)
public class ClipboardPluginAosp extends ClipboardPluginBase {
    private final ClipboardManager clipManager;
    public ClipboardPluginAosp(Context context) {
        this.clipManager = (ClipboardManager) context.getSystemService(Context.CLIPBOARD_SERVICE);
        nativeInit();
    }
    @Override
    public void setData(String data) {
        if (clipManager != null) {
            ClipData clipData = ClipData.newPlainText(null, data);
            clipManager.setPrimaryClip(clipData);
        }
    }
}

The same pattern is used on iOS, with the bridge classes calling the native iOS clipboard APIs.

Conclusion

This chapter covered ArkUI‑X environment setup, project creation, build and packaging, the ArkTS‑to‑ArkUI compilation pipeline, and the Android/iOS integration mechanisms, including a concrete clipboard example. ArkUI‑X adds another viable option to the mobile cross‑platform ecosystem, borrowing proven ideas from existing frameworks while offering its own declarative approach.

References

ArkUI‑X repository: https://gitee.com/arkui-x

arkui_ace_engine repository: https://gitee.com/openharmony/arkui_ace_engine

Deep dive into arkui_ace_engine: https://juejin.cn/post/7305235970286485515