目录

Overview

This topic describes the definition and objectives of one-time development for multi-device deployment (one-for-multi for short), and provides device-to-device guidance from the perspectives of UX design, page development, and feature development, helping you quickly develop apps that adapt to various types of devices. Before developing an app, you should fully consider the scenario where the app can be run on multiple devices, avoiding significant adjustment to the app architecture when new types of devices are added.

This series focuses on the general basic guidance for multi-device adaptation. For more information about the hardware parameters and experience optimization design of specific devices, see Multi-Device Experience Optimization.

Background

As terminal devices grow more diverse in form and scale, the number of smart devices per person and per household will keep rising. This makes connectivity and collaboration between multiple devices increasingly critical—by tapping into the unique strengths of different device forms, we can deliver a dramatic leap in user experience. When interacting with devices, users will gradually move away from the current device-centric model toward a scenario-centric model. In any given scenario, each device brings its unique features to the table, fostering cross-device support and collaboration—while app services work across devices to deliver seamless task completion.

For app developers, a wide range of device types can also bring a large number of potential users to the app. However, if an app needs to provide same content on multiple devices, different screen sizes and hardware devices need to be adapted. As a result, development costs are relatively high. This is where one-for-multi capabilities, provided by HarmonyOS, come into the picture, allowing you to efficiently build apps that can run on multiple devices based on one design.

Chapter Overview

The chapters in this guide are described as follows:

Key Technologies

To implement one-for-multi app development, address the following three issues:

To address these issues, HarmonyOS provides solutions in terms of page adaptation, feature compatibility, and code deployment.

NOTE

Development Process

Once the requirements for an app are clarified, its development process typically includes the following steps: experience design (including UI UX design and service feature design), architecture design, UI development, and feature development. Cross-device apps follow this same process, and this guide is structured accordingly. By leveraging the system capabilities of HarmonyOS, create a complete technical path to develop a single codebase that can be deployed on various devices. This aims to support developers in quickly and efficiently developing apps for various devices, ensuring compatibility with different devices while providing a distributed experience of cross-device hopping, migration, and collaboration.

[h2]Experience Design

For cross-device app development, you are advised to incorporate considerations for multi-device adaptation early in the product design phase. Through unified planning, we can achieve consistent cross-device feature layout and user experience.

For cross-device apps, differentiation, consistency, flexibility, and compatibility should be incorporated into UX design principles.

For details about UX design in one-for-multi development, see Cross-Device Experience Design.

[h2]Architecture Design

To realize one-time development for multi-device deployment, sound app architecture design is crucial for HarmonyOS apps. This enables them to support Huawei 1+8 all-scenario devices—such as smartphones and PCs/2-in-1 devices—through a single code project and one build. To address these issues, developers should focus on layered and modular architecture design, which can clarify service logic, reduce code coupling, achieve flexible deployment and module-level reuse, and meet the deployment requirements of multiple devices such as smartphones, foldable phones, tablets, and PCs.

For details about the architecture design principles, see Layered Architecture Design and Modular Design.

[h2]Page Development

[h2]Feature Development

SystemCapability (SysCap) refers to a standalone feature in the operating system, such as Bluetooth, Wi-Fi, NFC, and camera. Each SysCap corresponds to multiple APIs, whose availability depends on the support of the target device.

During cross-device app development, the default required SysCap set is an intersection of multiple supported SysCap sets, and the default associated SysCap set is a union of multiple supported SysCap sets. An app can be distributed, installed, and run on a device only when the required SysCap set is a subset of the device's supported SysCap set. Therefore, the SysCap mechanism can be used to intercept and control operations at each phase to ensure that apps are installed successfully and function correctly on target devices.

For details about how to develop cross-device features, see Cross-Device Feature Development.

Scenario Cases

Leveraging the one-for-multi capabilities provided by HarmonyOS, you can efficiently adapt to multiple vertical service scenarios based on a single code system, enabling cross-device and cross-form app deployment. By flexibly utilizing this system-level feature, you cannot only ensure that your apps cover various device forms—such as smartphones, tablets, and wearables—but also quickly respond to diverse needs from industries like finance, healthcare, education, and transportation. This comprehensively boosts your app development efficiency and deployment quality.

[h2]Service Scenario Cases

Adapt the one-for-multi feature to multiple scenarios to deliver a better browsing and interaction experience. The following are design suggestions provided for typical pages in specific vertical scenarios.

[h2]Device Scenario Cases

Adaptation to different devices can make full use of their hardware features, such as the semi-folded state of foldable phones and large screens of tablets and PCs/2-in-1 devices, to provide a better experience.

Basics

This section describes some basic knowledge for you to better understand the upcoming chapters.

[h2]ArkUI

ArkUI is a UI development framework that provides what you'll need to develop app UIs.

ArkUI comes with two development paradigms: JavaScript-based web-like development paradigm (web-like development paradigm for short) and ArkTS-based declarative development paradigm (declarative development paradigm for short).

The following table compares the two development paradigms.

Development Paradigm

Programming Language

UI Update Mode

Applicable To

Intended Audience

Declarative development paradigm

ArkTS

Data-driven

Apps with high complexity and intensive team collaboration

Mobile app and system app developers

Web-like development paradigm

JavaScript

Data-driven

Small- and medium-scale apps and service widgets with simple UIs

Frontend web developers

The declarative development paradigm occupies less memory. It is recommended that you use this development paradigm to set up app UIs.

[h2]Project Structure

Based on a single code project, the layered architecture design of HarmonyOS apps aims to support Huawei 1+8 all-scenario devices, such as smartphones and PCs/2-in-1 devices, achieving one-time development for multi-device deployment. The layered architecture consists of product customization layer, basic feature layer, and common capability layer, providing a clear, efficient, and scalable design architecture. The following three-layer project structure is recommended for app development.

The abstracted code structure is as follows:

/application
├── common                  # Optional. Common capability layer, which will be compiled into one or more HARs or HSPs.
├── features                # Optional. Basic feature layer.
│   ├── feature1            # Sub-feature 1, which will be compiled into a HAR, an HSP, or a feature HAP.
│   ├── feature2            # Sub-feature 2, which will be compiled into a HAR, an HSP, or a feature HAP.
│   └── ...
└── products                # Mandatory. Product customization layer.
    ├── wearable            # Category of wearables, which will be compiled into an entry HAP.
    ├── default             # Category of default devices, which will be compiled into an entry HAP.
    └── ...

  • The code structure varies with the deployment model. The main differences between deployment model A and model B lie in the products layer. In model A, functions and features are integrated in the same subdirectory under the products directory. In model B, differential functions and features are integrated for different products in different subdirectories under the products directory.

  • In the development phase, maximize the code reuse among different types of devices to reduce the workload of development and subsequent maintenance.

  • The entire code project is built into an application package, which will be released to the AppGallery.

  • For details, see Layered Architecture Design.

[h2]Application Bundle Structure

During app development, an app usually contains one or more modules. As a basic functional unit of apps/atomic services, a module contains source code, resource files, third-party libraries, and app/atomic service configuration files. Each module can be built and run independently.

Modules are classified into two types: Ability and Library.

An app is released as an APP Pack, which contains one or more HAPs. A HAP is the basic unit for app installation and it can be classified into two types:

For details about the entry HAP, feature HAP, HAR, HSP, and APP Pack, see Application Package Structure in Stage Model.

[h2]Deployment Model

There are two one-for-multi deployment models:

You can choose one of the two deployment models based on the app UX design and features in specific service scenarios. Also, you can quickly choose the appropriate model by device type.

Based on the screen size, interaction mode, and interaction distance, devices can be classified into the following categories:

For devices of the same category, model A is preferred. For devices of different categories, model B is preferred.

  • Model A is applicable when minimal variations exist in UX designs or features across different categories of devices.

  • Model B is applicable when significant variations exist in UX designs or features across different devices of the same category. Ensure that these designs and features are properly implemented for each device.

  • The concepts of the two deployment models are introduced to help you better understand the basic knowledge. During cross-device app development, if there are multiple types of target devices, model A and model B are usually used together.

  • No matter which model is used, one-time build should be performed.