MiniApp Standardization White Paper version 2

W3C Group Draft Note

More details about this document
This version:
https://www.w3.org/TR/2022/DNOTE-mini-app-white-paper-20220528/
Latest published version:
https://www.w3.org/TR/mini-app-white-paper/
Latest editor's draft:
https://w3c.github.io/miniapp/white-paper/
History:
https://www.w3.org/standards/history/mini-app-white-paper
Commit history
Editors:
Qing An (Alibaba)
Dan Zhou (Baidu, Inc)
Martin Alvarez-Espinar (Huawei)
Zitao Wang (Huawei)
Wanming Lin (Intel Corporation)
Kaining Yuan (Intel Corporation)
Canfeng Chen (Xiaomi)
Yinli Chen (Xiaomi)
Anqi Li (W3C)
Fuqiao Xue (W3C)
Former editors:
Dapeng Liu (Alibaba)
Hongru Zhu (Alibaba)
Qingqian Tao (Baidu, Inc)
Zhixing Lei (Baidu, Inc)
Lei Zhao (China Mobile)
Zhiqiang Yu (Huawei)
Xiaowei Jiang (Xiaomi)
Feedback:
GitHub w3c/miniapp (pull requests, new issue, open issues)
public-miniapps-wg@w3.org with subject line [mini-app-white-paper] … message topic … (archives)

Abstract

This document introduces a new format for mobile applications, named MiniApp, which is a very popular hybrid solution relying on Web technologies but also integrates with capabilities of the native apps.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the MiniApps Working Group as a Group Draft Note using the Note track.

Group Draft Notes are not endorsed by W3C nor its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The W3C Patent Policy does not carry any licensing requirements or commitments on this document.

This document is governed by the 2 November 2021 W3C Process Document.

1. Introduction

1.1 Problems

Native apps are well received in our daily life, but there are still many things that can be done better for users.

The Web is an ideal platform to avoid these problems, but it's still imperfect by far.

1.2 What is MiniApp?

MiniApp is a new mobile application format, a hybrid solution that relies on Web technologies (especially CSS and JavaScript) and integrates with the capabilities of native apps.

A super app is a software platform that hosts and supports other applications (i.e., MiniApps), enabling their execution by using the platform's resources.

MiniApps got popular from their usage on a few super apps, as it was born with a few characters that helped fill the gap between the Web and the native.

1.3 Gap between MiniApps and PWA

MiniApps are not aimed to replace Progressive Web Applications (PWA), native apps, or the Web.

In broad terms, one of the significant differences between these technologies is the execution environment. PWA may run in almost any web-enabled environment in a browser, while MiniApps are bound to specific platforms or super apps. Another essential difference is the distribution mechanisms, with MiniApps packed and self-contained and the PWA's resources distributed across the Web.

Both technologies use similar programming and markup languages and CSS-based stylesheets in terms of coding. MiniApps implements dedicated domain-specific languages based on HTML subsets and specific mechanisms for data binding and event management, following the MVVM paradigm with Virtual DOM management. MiniApp vendors define similar UI (User Interface) elements that do not always have a direct equivalent in HTML.

In terms of services, PWA and MiniApp developers have access to APIs with the same purpose and equivalent features but do not follow the exact specifications.

MiniApp vendors define exclusive APIs oriented to the app release and distribution management through their channels. Other dedicated APIs are tied to concrete scenarios and the running platform -e.g., services to set up reminders using the device's native alarm and calendar features, perform phone calls and trigger performance warnings. Although both technologies have similar APIs and services, there is a significant gap between the API specifications in each application type. PWAs rely on standard Web APIs, while MiniApps implement non-standard APIs to maximize the platform's capabilities, such as device-specific features and vendor-exclusive services.

Depending on the implementation, a MiniApp user agent could be an operating system, a super app, or any other hosting platform based on different and various rendering engines and WebViews. The architecture of a MiniApp user agent differs from PWA user agents, as we can see in the following picture.

The architecture of MiniApps and PWA
Figure 1 The architecture of MiniApps and PWA

The comparison table in the annex identifies and highlights the differences between Progressive Web Applications (PWA) and various MiniApp implementations. Some of these differences are summarized in the following table.

Feature Progressive Web App MiniApp
Source code Standard markup languages (HTML), stylesheets (CSS), and scripts (JavaScript). Non-standard dialects of HTML, CSS and JavaScript
Deployed Format Web resources (mainly: HTML, CSS, JavaScript code, and WebAssembly modules) HTML, CSS, JavaScript, and other resources packed in a ZIP container.
Packaging No. Resources linked on the Web. Yes. Different package formats per vendor.
Needs to host files on Web server Yes No
Installation-free usage Yes, running in the browser. Running in a super app or on the OS.
Installation with standalone icon From the browser or app marketplace (optional) No
Services Access to Web APIs Access to non-standard Web APIs, including some system native APIs

1.4 Case studies

1.4.1 Case 1: Shared Bicycle Service

The popularization of MiniApps helps make the shared bike a seamless service instead of a cumbersome application.

  • A user chooses any of the MiniApp platforms on their mobile device, which is usually a super app that they already logged in to;
  • A user scans the QR-code label attached to a shared bicycle within the super app;
  • The hosted app will automatically navigate to the shared bicycle MiniApp and unlocks the bicycle instantly;
  • Upon arrival, the user locks the bike on the MiniApp;
  • The transaction completes, and a message of the payment detail is sent to the user.
Shared Bicycle Service
Figure 2 Shared Bicycle Service with MiniApp

For users, MiniApps can bring convenience from a few perspectives:

The Web Native app MiniApp
Download/install No Yes No
Verified/trusted No Yes Yes
Login/register Yes Yes User permission
Payment Send a payment request Register a credit card or navigate to another app Complete within the hosted app

1.4.2 Case 2: AR Zoo

MiniApp developers can simply use HTML/CSS/JavaScript as the programming language, but MiniApp is more flexible, so it excels at quickly developing complex features in daily work.

This MiniApp tries to build an AR zoo with AI technologies to recognize the animals. Developers can easily do that by adding a few components or APIs that provide access to the native capabilities or advanced features (e.g., image recognition, AR 3D animal-model rendering, a speech API for speech synthesis, and AR navigation provided by the map SDK).

MiniApps can be discovered by the search engines, by search engines, MiniApp stores in the hosted app, or QR codes.

AR zoo
Figure 3 AR Zoo MiniApp

For the developers, the incentive to work on MiniApps is very obvious.

The Web Native app MiniApp
Discoverability Search engine Marketplace Multiple: search engines + MiniApp store in the hosted apps + QR code
Verified/Trusted Still exploring By native app marketplaces By host app platforms
Deploy/Reload Load/reload the webpage Installed/reinstalled Load/reload as it's using a JavaScript engine
Programming Language Web programming language New/multi languages: iOS and Android, at least Web programming language
APIs/Components (AR, Image Recognition, Geolocation, Speech API) Very basic Complex for Web developers Very simple high-level APIs and components

1.4.3 Case 3: MiniApp for Vehicle

One of the goals of MiniApp is to connect information and services across different platforms, so it's ideal for IoT applications such as Smart Automotive, voice-control speakers, and Smart TV.

Nowadays, it's possible to convert some MiniApps to adapt the vehicle screen and system. Also, a few MiniApp vendors have built a MiniApp platform specially designed for the vehicle system to help distribute or upgrade applications to various car models. This brings millions of Web developers to the Automotive application ecosystem.

These Automotive MiniApps can service many user scenarios, including gas filling, car washing, electronic toll collection, insurance, restaurant reservation, or entertainment. For example, when the system detects the remaining fuel is less than 20%, it can recommend to the owner a Gas Pumping MiniApp. The user can get the information of the nearest gas station and head there to complete the gas pumping, including the payment within MiniApp, "refueling without getting off the vehicle".

smart car
Figure 4 MiniApp for smart car (gas pumping app)

1.4.4 Case 4: MiniApp for IoT

IoT device is becoming another carrier running MiniApps. MiniApp for IoT intends to enable interoperability across multiple IoT device platforms and operating systems. Rather than dealing with the difference across the multiple IoT device platforms and IoT operating systems, by introducing MiniApps for IoT, developers only need to focus on the application development on IoT devices.

One example is the HVAC (heating, ventilating, and air-conditioning) application switch panel, which has a screen and several physical buttons. In this case, by introducing MiniApp for IoT, the switch panel’s screen UI can be designed and developed using Web technologies to display the HVAC information. For example, the target temperature value inputted by the physical and the measured real-time temperature value can be displayed.

IoT MiniApp
Figure 5 IoT MiniApp running on HVAC application switch panel having a screen and several physical buttons

Another example is smart speakers with a touch screen. In this case, by introducing MiniApp for IoT, the smart speaker’s touch screen UI can be designed and developed using Web technologies to play music and video, control the IoT devices at home, and shop online.

IoT MiniApp on smart speaker
Figure 6 IoT MiniApp running on a smart speaker with a touch screen

1.4.5 Case 5: MiniApp for TV

Unlike MiniApps running on mobile phones, where user interaction depends on the touch screen, the user interaction of MiniApps running on TV switches to the TV remote panel keyboard plus TV screen focus.

With MiniApp for TV, users can buy merchandise on TV through E-commerce MiniApp.

E-commerce MiniApp running on TV
Figure 7 E-commerce MiniApp running on TV

And also, users can play games on TV through Gaming MiniApps.

Gaming MiniApp running on TV
Figure 8 Gaming MiniApp running on TV

2. MiniApp Overview

2.1 Core Features

2.1.1 Separate the view layer from the logic layer

In a MiniApp, the view layer is usually separated from the logic layer.

Logic layer and view layer
Figure 9 General architecture of MiniApps

The view layer is responsible for rendering MiniApp pages, including Web components and native components display, which can be considered hybrid rendering. For example, some Web components might not be supported by the WebView or have performance limitations, so MiniApp also relies on native components such as map, video, etc.

The logic layer is implemented with JavaScript Workers. A worker is responsible for MiniApp’s event processing, API calls, and lifecycle management.

Extended native capabilities usually come from the hosting native app or OS, including payment, file processing, image scanning, phone calls, etc. These features are called through specific APIs. When a MiniApp calls a native API, it transfers the API call to extended native capabilities for further processing via a JavaScript Bridge. It obtains the result from the extended native capabilities via the JavaScript Bridge.

data flow of MiniApp when an API is called
Figure 10 Data flow of MiniApp when an API is called

The worker establishes a connection for each Render, transferring the need-to-be-rendered data to the Render for further processing.

If an event is triggered by a component in a MiniApp page, this page’s Render will send the event to the worker for further processing. At the same time, the Render will wait for the data sent from the worker to re-render the MiniApp page.

The rendering can be considered stateless, and all the states will be stored in the worker.

The benefits of separating the view layer and the logic layer include:

  • Very handy for data sharing and interaction among multiple MiniApp pages.
  • Having the same context within the lifecycle of MiniApp can provide a similar coding experience for those developers coming from native app development background.
  • Separation and parallel implementation of render and JavaScript worker can prevent the situation where a JavaScript execution impacts or slows down the page rendering, which can help enhance the rendering performance.

2.1.2 Rich APIs and Components

MiniApp platform provides many components to help developers build a fancy UI, including essential components like view, form, image, and high-level components like maps.

MiniApp vendors also offer many APIs for developers to access both the Web and the native capabilities, including basic interfaces such as UI display APIs, image processing API, and those advanced ones like user account API, map API, and payment API.

APIs usually work together with components. When a user clicks a certain component on a MiniApp page, it will call the related API to complete the user’s interaction and refresh the current MiniApp page if needed.

2.1.3 MiniApp Constructor

In order to obtain similar user experiences as in native apps, MiniApp resources are usually packaged together. After downloading and installing a MiniApp package, all the static resources (i.e., page templates, CSS, JavaScript files, and other documents) required by the MiniApp persist on the users' devices. These resources are always available without any redundant downloads until the next update.

A MiniApp package is a compressed ZIP archive, including:

  • A configuration document located in the root directory of the package. The config file should include:
    • the general description of the entire MiniApp; and
    • the description of the pages, including their corresponding paths and configuration, for page setup and opening.
  • One app-level logic file containing a script to deal with app-level lifecycle callbacks.
  • One or several files, containing templates code for page structure, CSS stylesheets for page styling, and JavaScript codes for the page logic.
  • Digital signature support for integrity validation.

For the purpose of locating a specific MiniApp while searching and executing, a MiniApp must have a package name or an identifier on the platform. An icon is also required for user recognition.

2.1.4 MiniApp Widgets

In addition to MiniApp pages, MiniApps can also be displayed as information fragments or MiniApp widgets. In this form, developers can put their service and/or content to various host scenarios, called host environments (e.g., assistants, global search of the device, etc.). This feature connects the services and content of the MiniApp with the concrete scenario, providing users with more convenience.

For example, when a user purchases a train ticket for a trip, the MiniApp widget on the smart assistant shows the train's latest status immediately. The user can click on this widget and jump to a full-screen MiniApp page for more detailed information.

Widget from the home screen to a MiniApp
Figure 11 Widget from the home screen to a MiniApp

Like in a MiniApp page, a widget is also described by URI scheme. The host environment specifies the MiniApp package and the corresponding widget to be loaded through its URI path and passes data to the widget through URI query parameters. After the widget is loaded, it is displayed and rendered in the host environment. Data from the host and widget, as well as data from different widgets are isolated to ensure security and independence.

In many scenarios, a widget can open a MiniApp page for more complicated operations. In such cases, widgets often need to share data with their corresponding MiniApp (e.g., maintain a consistent login status). Therefore, the data of the widget and the MiniApp can be accessed from each side. In other words, the MiniApp widget and the page have same data access rights.

widget interaction
Figure 12 MiniApp widget interaction

One of the goals of the widget is to let the user forget the traditional app concept and truly meet the user's needs in the form of service. So, in addition to all app invocation paths, widgets can also be triggered by different methods in different scenarios, such as text keywords, voice analysis, picture recognition, scan code, and event intent.

Note: Widget is implemented by Quick App in China market.

2.1.5 Single-Instance, Multi-Entries

There are multiple entrances to discover, open and access MiniApps. Unlike the Web content in multi WebViews, only one instance will be created for the same MiniApp, so MiniApp keeps its status and data in a consistent manner globally. For example, after one user opens and logs in to a MiniApp through the entrance of a QR code for the first time, the user will remain logged in the next time when the user returns from another entry like a MiniApp store.

The entries for MiniApps include, but are not limited to:

  • MiniApp marketplace
  • Search engine
  • Smart assistant
  • QR code
  • SMS/text
  • Physical object (with AI)
  • Browser
  • Calendar items
  • Voice message (with AI)

2.1.6 Performance and User Experience

MiniApps try to improve their performance and user experience with a few mechanisms that have been proved to be effective through practice.

Packaging

With MiniApp's constructor, a user only needs to download the package when the MiniApp is first opened, and then the static resources (e.g, pages, scripts, and CSS) in the MiniApp needn't be downloaded again, so that the loading and jumping of the following pages are more efficient. This feature improves user experience and saves network traffic.

Meanwhile, the MiniApp has a pre-download mechanism, which can download the MiniApp packages in advance, or pre-downloads separately for the first page, and perform streaming decompression in parallel during download to minimize the time-consuming of MiniApp startup phase and balance the loss of the first page performance when opening first time.

Multiple Rendering Views

The MiniApp uses native page stack management between render views, and the page switching is driven by native code. Therefore, the gesture operation in the page, the switching between pages can achieve the exact same smooth experience as native.

Because of the isolation of the view and logic layers, the view layer can be rendered independently. Without being blocked by JavaScript logic code, the rendering speed of the page can be greatly improved.

Pre-built and reuse of runtime environments

MiniApp's runtime environment is usually pre-built before launching a mini-app, thus reducing the time to launch a MiniApp. Pre-built content includes rendering views, static resources, developer-defined prefetch requests, and MiniApps runtime container. After a MiniApp is activated, it will take over the pre-built rendering view, and then we will continue to pre-build a new render view into the cache pool for the next one. There is a limit on render view quantity. When any render view gets closed or the quantity limit is exceeded, the oldest opened render view will be destroyed. When the MiniApp application exits, the runtime is destroyed, and the application environment and resources can be reused.

Pre-defined Component and API

MiniApp platforms provide very rich components and APIs. These components and APIs are usually well designed to meet the developers' performance requirements.

JavaScript framework presets and hot reload

MiniApp's runtime environment contains two major parts, the basic capabilities provided by native code and a framework, including developer API and some components implemented by JavaScript. The JavaScript framework is built in native apps and will be loaded into the MiniApp runtime environment in advance before executing the MiniApp. The JavaScript framework can be hot reloaded (reload during usage), which brings lots of possibilities to improve performance.

2.1.7 Login

The MiniApp platforms provide a variety of ways for a user to log in to the MiniApp. If the user has already logged in to the platform with identity authentication, the login information of the platform can be shared with MiniApp, quickly realizing the interoperability of MiniApp’s own account system and the platform account system, which makes the access process of the MiniApp more smooth.

For example, the traditional login process with SMS verification is more time-consuming; users need to manually enter their cell phone number first and then enter the verification code after receiving the SMS to log in. The advantage of MiniApp is that developers can use the components / APIs provided by the platform to obtain users' cell phone numbers securely and conveniently, prompting the user to authorize a one-click login process with their cell phone numbers, which makes the entire process simple for the user and reduces the cost of obtaining user information for developers.

Sign in to a MiniApp
Figure 13 Sign in to a MiniApp

2.1.8 Subpackaging

MiniApp subpackaging is a build mechanism for improving the MiniApp package development process. It helps developers divide different business modules into different subpackages.

For developers: a MiniApp has the main package by default; it contains the startup page files and public resources. Subpackage is a building type that flexibly divides the developer's business modules. Users can open special pages after loading different sub-packages on demand.

For users: when the user starts the MiniApp, the main package will be downloaded by default, and the page in the main package will be launched. If the user needs to open a page in the subpackage, the MiniApp Runtime will start to download and load the subpackage and start the subpackage page.

Through such a subpackage building mechanism is better to decouple and collaborate when multiple teams develop together. When users use the MiniApps, the subpackaging mechanism can improve the loading speed of the MiniApp homepage, load subpackages on demand, and optimize the user experience.

2.1.9 Add-ons

In a MiniApp, an add-on/extension is an encapsulated module that adds a specific feature to an existing MiniApp, and it could be a component, a JavaScript module, or a page. The add-on/extension can only be executed in a MiniApp instead of running separately. Developers can develop an add-on/extension just like a MiniApp, and upload it to the MiniApp platform for other MiniApps to reuse.

MiniApp supports add-on/extensions to:

  • reduce development costs by code reuse and help developers easily add new features
  • update functionality automatically without the awareness of developers
  • reduce the package size of MiniApps by not loading unused functions

The add-on/extension mechanism lowers the barriers to developing MiniApps and brings more developers to the MiniApp ecosystem.

2.2 MiniApp Market

This section describes a few current mainstream MiniApp or relevant platforms.

Alipay Mini Program

Alipay Mini Program runs on top of Alipay native app, which is a hybrid solution of Web and native. Alipay Mini Program relies on Web technologies like CSS and JavaScript. Meanwhile, it integrates the functionalities of Alipay native app as payment, credit service, face authentication, etc.

More than 1 million Mini Programs are running on Alipay native app, with 230 million DAU (Daily Active User). The user scenarios include retail, transportation, medical services, etc.

Baidu Smart Mini Program

Baidu Smart Mini Program refers to an open ecological product that intelligently connects people to information and services based on the Baidu app and other partners’ platforms. Through Baidu’s AI abilities and understanding of all contents in Smart Mini Programs, Baidu accurately connects users and Smart Mini Programs. With Baidu’s search and information flow dual engine, users can achieve an app-like experience within Smart Mini Programs. As of July 2019, there are over 150,000 Smart Mini Programs and 270 million MAU.

Baidu Smart Mini Program is open-sourced within our open source alliance, with more than 30 cooperators, covering super apps, mobile OS, car OS, voice-control speakers, and TV.

Quick Apps (Quick App Alliance, including Xiaomi and Huawei)

Quick App is a MiniApp standard developed by 12 top mobile phone manufacturers in the Quick App Alliance, covering over 200 million MAU. Developers can achieve one-time development and run on all hardware vendors' platforms. Quick Apps, which are deeply integrated into the operating system, can be obtained in multiple scenarios of the mobile phone system with just one click. By introducing a native rendering path, an effective combination of front-end development and native performance experience is achieved.

Quick Apps can run in two forms: Quick App page form, like native app page, and a widget form that presents information in the scene. The two are adapted to different user needs, connecting the system and the MiniApp into a whole in multiple scenarios.

360 PC MiniApp

MiniApps on PC is still in an early exploration stage. 360 PC MiniApp is a light application running in their PC browser. Compared to the traditional webpages, it's served with more functionalities and easier interaction with the PC operating system.

PC MiniApps are only available to those validated as an enterprise account. Most of the features are under strict regulations so that they can be considered highly trusted Web content.

PWAs

PWAs are the latest term to summarize modern Web applications. As a counterpart of native apps, a PWA looks and feels like a native app and can be installed on the device home screen/launcher/start menu; it can send push notifications to re-engage users; it can be used when offline and behaves under poor network conditions; it works with devices of wide-ranging capabilities, and it's still evolving to works with new capabilities defined by open Web standards; payments can be made by user inside PWAs apps; and PWAs apps are search-engine-friendly, working perfectly with hyperlinks. PWAs are successful in technical and business aspects (widely adopted by many websites, especially in consumer-facing ones).

3. Working with the Web

This section selects some typical use cases and proposes a few APIs that MiniApps would like to have support from the Web.

3.1 Application Lifecycle

3.1.1 Hybrid Rendering

MiniApp is a hybrid solution of Web rendering and native rendering. It'd be great if there is a good way to combine the rendering results from the Web and the native.

Rendering results coming from both the Web and the native
Figure 14 Rendering results coming from both the Web and the native

Proposal: MiniApp needs a standardized API to help integrate the native rendering result into the Web rendering outcome.

3.1.2 Transition Animation

MiniApp would like to provide transition animation during page switching so that users can have a similar experience as when they are using a native app, but it's almost impossible to do that now.

Proposal: MiniApp needs an API to add transition animations during MiniApp page switching.

3.1.3 Standardise the Package Constructor of MiniApp

MiniApp can form a package and parsing convention for multiple MiniApp hosting platforms through a standardized distribution format. Currently, each MiniApp hosting platform provides different development tools (different packaging methods), and the MiniApp is parsed differently in different MiniApp hosting environments.

Proposal: The MiniApp is actually a packaged (compressed) collection of files during the distribution process. We can describe a MiniApp (.ma) with a uniform file suffix and specify how to create the .ma file and how to parse the .ma file.

3.1.4 Standardise the navigation to a MiniApp page

For a hot page in a MiniApp, it may be referenced in another MiniApp, and it is expected to be accurately evoked when the user visits.

Proposal: Define a standardized protocol (URI scheme) to access MiniApp.

3.1.5 MiniApp Widgets

Like Android widgets or Apple dashboard, users can directly get information and/or finish their task with a MiniApp widget without opening any Web or app pages. A MiniApp widget can be displayed in an environment outside of Web browsers, such as on desktops or dashboards.

Proposal:

  • A MiniApp widget can be displayed within a host environment, either a WebView or a native app page. The host environment loads a widget with its corresponding URI path, which describes a package and widget page.
  • A MiniApp widget can access local data or data from a server. Meanwhile, a MiniApp widget can communicate with MiniApp in the same package.
  • A MiniApp widget should be interactive, meaning that it should be responsive to any user behaviors/interactions. A MiniApp widget should have the ability to open a Web or app page.

3.2 Performance and Tuning

3.2.1 Define an event for "time to interactive" in MiniApp

MiniApp needs to know when the MiniApp page Time to Interactive (TTI) has been completed.

Proposal: A standardized event to notify that the MiniApp page Time to Interactive has been completed.

3.3 Graphics and Media

3.3.1 3D Model Element

3D models have become more and more popular thanks to their rich details. Combined with AR, they will provide a better user experience than 2D. The business cases might include online shopping, advertisement, education, etc. However, the current Web lacks a standard and convenient way to deal with 3D models. In this document, we propose to define an HTML tag to directly handle 3D models, similar to the way we handle audio, video, and image with corresponding HTML tags:

  • 360 view

    Users can view a 3D model from different angles via gestures. And the 3D model can be zoomed in/out as well. It can be viewed on full screen or embedded in an webpage, shown together w/ other HTML contents.

  • View with AR

    Users can place the 3D model in the real world with the camera. Users can specify different locations to place the model.

Proposal: A <xmodel> element to specify a 3D model on the Web and power interactive 3D contents with AR.

3.3.2 Face Tracking

Face tracking can be used in many 3D scenarios.

Face Effects in Live Video
Add effects on the face in live video. These effects include a full-screen filter, face reshape and makeup, 2D sticker, 3D headdress, etc. Most of these effects depend heavily on real-time face tracking from a video source.
Gaming
Game developers can design game strategies based on the tracked face, like triggering a specific game logic when the eye blinks or checking if the dropping fruit is in the opened mouth.
Virtual Makeup
Let users try lipsticks, eye shadows, glasses, and hats on the product page to help them decide.

Proposal: A Face Tracking API use a video element as input and updates face tracking output every frame, which includes:

  • Bounding box of each face
  • 4x4 pose matrix of each face
  • Normalized (x, y) landmarks points
  • Face geometry data including vertices, normals, texture coordinates

3.3.3 Hand gestures tracking and recognition

Hand gestures can be used in video effects and AR/VR game scenarios to make apps more impressive and interactive.

Proposal: A high-level API to track hand movement and get the hands outline.

3.3.4 Low level AR APIs based on ARCore and ARKit

There are a few AR APIs in MiniApps we would migrate to the Web, as they help provide a better AR experience in gaming, 3D model preview, and interactive ads.

Proposal: Provide low-level AR APIs based on ARCore and ARKit, which include:

Camera view matrix for world tracking
Provide the 4x4 view matrix of the spatial location and orientation of the mobile phone, which can be used to update the camera matrix in their 3D virtual world in real-time by developers. Thereby the position of the real world can be correlated with the position of the object in the virtual world.
Plane detection and tracking
Detect planes in the real world and track these planes in real-time. Provide the 4x4 transform matrix, which represents the center position and orientation of each plane. It can be used for placing 3D virtual objects on the ground/desktop.
Anchor
Anchor defines a fixed position and orientation in the real-world. Developers can create an anchor from a 4x4 transform matrix, which can be got by hit test. This matrix will be updated each frame to ensure that the virtual object corresponding to the matrix can be fixed in one position and direction in the real scene.
Hit test
Get a 4x4 transform matrix representing a position and orientation in the real world space corresponding to the screen position to implement functions such as clicking and placing virtual objects.
Better support for AR
Figure 15 APIs to better support AR

4. Current standards work; the WG work

4.1 Lifecycle

[MINIAPP-LIFECYCLE] defines the MiniApp lifecycle events and the process of managing MiniApp and each page's lifecycle. Implementing this specification enables the user agent to manage the lifecycle events of both the global application lifecycle and the page lifecycle.

As described in 2.1.1 Separate the view layer from the logic layer, in a MiniApp, the view layer is separated from the logic layer. The view layer is responsible for rendering MiniApp pages, including Web rendering and native rendering, which can be considered hybrid rendering. The logic layer is implemented with JavaScript Worker. The logic layer is responsible for MiniApp’s event processing, API calls, and lifecycle management.

MiniApp lifecycle mechanism provides a means to manage MiniApp's view layer and logic layer through the MiniApp global application lifecycle events and MiniApp page lifecycle events. Developing MiniApp with knowledge of the MiniApp global application lifecycle states and MiniApp page lifecycle states can lead to improved user experiences. MiniApp lifecycle includes a set of events, with which MiniApp can choose to alter its behavior based on its state.

4.2 Manifest

[MINIAPP-MANIFEST] is the specification that defines the set of metadata to describe MiniApps. The MiniApp Manifest extends the [APPMANIFEST] and the [MANIFEST-APP-INFO] specifications by providing additional mechanisms to set up basic information of a MiniApp, like identification, human-readable descriptions, versioning data, and styling information. The MiniApp manifest also configures the routing of the pages and widgets that are part of a MiniApp.

A MiniApp manifest is a JSON document that uses some basic elements of the Web App Manifest to describe a MiniApp (name, short_name, description, and icons), adding nine supplementary members to specify technical details about the MiniApp (app_id, version, platform_version, device_type, pages, req_permissions, and widgets) and configure the look and feel of the app (color_scheme and window).

4.3 Packaging

[MINIAPP-PACKAGING] defines the semantics and conformance requirements for a MiniApp package and the structure of the container that holds the resources of a MiniApp, including the page components (i.e., templates, stylesheets, and JavaScript logic), the manifest, and other media files or configuration resources.

This specification determines the logic and physical structures of MiniApps, holding the requirements in terms of file system organization and processing of the ZIP-based container that packs a MiniApp. Instances of the MiniApp package facilitate the MiniApp distribution and execution in runtime environments or MiniApp user agents.

4.4 Addressing

[MINIAPP-ADDRESSING] is a Note that defines a standard MiniApp protocol for accessing MiniApps. It aims to solve the problem that currently, each MiniApp vendor has its own way of describing a MiniApp resource and uses very different methods to obtain the MiniApp package, which makes it very difficult to access MiniApps across platforms and difficult to reach a unified understanding from both user and developer perspectives.

The document refers to mobile deep linking technology and defines two ways to access MiniApp, one with the HTTPS protocol and the other with a custom protocol. In addition, MiniApp Addressing defines the syntax of MiniApp URIs, including uri-prefix for cross-environment access, uri-infix "miniapp" for MiniApps, and identifier and version to uniquely identify a MiniApp.

MiniApp Addressing also describes how the user agent obtains the corresponding mini-app package based on MiniApp URI, as well as some error handling, and gives an example procedure for downloading MiniApp packages over the network.

4.5 Widget

MiniApp Widget is a special form of MiniApp Page. Same as a page, a widget runs in a host environment that is called the MiniApp user agent. Unlike a MiniApp page, a widget can occupy a certain area instead of the entire screen. The [MINIAPP-WIDGET-REQ] document describes the initial design considerations for developing a MiniApp Widget, including user agent, packaging, manifest, addressing, lifecycle, UI components, API, and communication between MiniApp and MiniApp Widget etc. The detailed Widget specification will be described in a separate document, which will describe the detailed technical requirement and capabilities of user agent. For example, the potential dependencies of widget running environment, the potential changes of API and UI Components brought by Widget, and new features bright by Widget such as the requirement of communication between MiniApp and MiniApp Widget. Both user agent developers and widget developers can refer to the Widget specification for technical development.

4.6 Implementation, converting tools

In 2021, the Working Group published two documents, [MINIAPP-MANIFEST] and [MINIAPP-LIFECYCLE]. Meanwhile, various vendors have some pre-standard implementations. To verify the feasibility of the standards and be compatible with pre-standard implementations, the working group developed a tool for converting MiniApp standard Manifest to different pre-standard manifest files, such as Baidu's App.json and HarmonyOS FA's config.json. And in a 2021 TPAC breakout session, the working group demonstrated a demo of the tool.

As the standards and pre-deployment progress, the working group plans to refine the tools to support a complete, standardized development approach that may include Packaging, Addressing, Lifecycle, UI components, and APIs.

5. New ideas incubated; the CG work

5.1 UI components

MiniApp components are the building blocks to define the structure, content, and logic of the pages that form a MiniApp. Each component encapsulates functionality, data, and styles, enabling developers to build reusable and customizable items.

The MiniApp UI Components specification collects a set of essential elements that developers can use to build homogeneous but customized user interfaces across MiniApp platforms.

This specification does not reference specific versions of HTML and CSS. It points to the latest W3C recommendations in order to guarantee the adoption and implementation of the changes to the HTML and CSS standards. Both MiniApp user agent vendors and developers will need to keep track of changes to these specifications to ensure that their processes and systems are kept up to date.

This specification defines a set of predefined elements that are common in all the MiniApp specifications, based on Web Components.

5.2 MiniApps for IoT

MiniApp for IoT describes the use cases of MiniApp for IoT. Derived from the use cases, this specification defines the architecture of MiniApp for IoT. How to reuse and extend the MiniApp Packaging and MiniApp Lifecycle is specified. Also, several APIs are specified for MiniApp APIs for IoT.

MiniApp for IoT has a similar architecture to MiniApps running on cell phones and PCs. But since IoT device has different hardware capabilities, MiniApp for IoT has its unique features, including:

6. Security and Privacy Consideration

MiniApp utilizes HTTPS to support secure connections. Multiple MiniApps within the same host environment are independent of each other.

User interactions within MiniApp need a different level of user permissions:

Permission User Interactions
Default (no extra action needed) Page sharing, clipboard, vibration, compass, motion sensors, map, screen brightness, screen capture, battery status
Permission on first-time usage Geolocation, camera (scan QR codes), network status, Bluetooth, NFC
Permission on every usage Contacts, file-apis, add to home screen, photo picker, phone call
Validate with token Push
Callback/messaging Password-free Payment
Request password Payment

From different perspectives and according to different security levels, the MiniApp framework provides the following methods.

6.1 Capability authentication

For capabilities with high privacy risks, MiniApp requires developers to apply for permission to use such features on the MiniApp developer platform. The application includes the rationale, a detailed description of the usage scenario, and the demo of usage. Then the platform will review applications according to the MiniApp usage requirements. Only approved MiniApps are allowed to invoke such interfaces. For example, the ability to obtain the user's mobile phone number is one of the capabilities with high-security risks.

6.2 User Authorization

For interfaces involving user privacy, the user's authorization must be required. MiniApp classifies these sensible interfaces into several authorization scopes such as location, album, address, camera, calendar, etc. For example, a window will be popped up (see figure below) when the MiniApp tries to invoke the camera capability but users don't authorize it. Thus, users understand that such privacy-related feature is protected. Meanwhile, MiniApps hosted by different super apps might have some different privacy authorization scopes based on the usage characteristics and usage scenarios of each super app.

User Authorization
Figure 16 User authorization

6.3 MiniApp Audit Review

MiniApp packages will be reviewed by MiniApp platforms before publishing. Developers must follow MiniApp Platform Operation Terms because the platform is the only way for them to publish a new version MiniApp. There are many aspects of platform auditing, such as data collection, data use, data security, and geographic location.

6.4 Domain check

For some container components, like <web-view>, that could render online webpages, MiniApp user agents may limit the URLs accessed by the component. Only the domain configured in the MiniApp Management Center can be accessed in <web-view>. Also, if the component contains an <iframe>, the URL opened by the iframe should also be configured in the MiniApp Management Center. In this way, MiniApp platforms can have more robust control over the dynamic pages opened by the MiniApp.

Similarly, the MiniApp framework verifies the legitimacy of the asynchronous request address.

For example, for URLs launched by request, download, upload, etc., their domain must belong to the domain configured in the MiniApp Management Center, and their protocols must be HTTPS protocols to ensure the security of data transmission.

7. MiniApp Standardization in the Globe

Though it originated in China, MiniApp is increasing in popularity around the globe. Similar product forms are raised in other parts of the world, including Japan, Korea, Southeast Asia, the US, Europe, and Africa. The standardization of MiniApp technologies has drawn considerable attention from the global Web community. Thus, the collaboration on MiniApp standards becomes a joint international effort.

7.1 Broader Web Community Discussions on MiniApp

The first global Web community discussion on MiniApp standardization was during TPAC 2019 in Fukuoka. A breakout session was organized during which MiniApp vendors introduced MiniApp technologies and the necessity for MiniApp standards. The participants discussed the possible directions for MiniApp standardizing, such as packaging, manifest, lifecycle, and widget. Special efforts were made to avoid the overlapping between MiniApp standards and the current Web standards efforts and enhance the interoperability between MiniApp platforms and the Web and between different MiniApp platforms. The MiniApps Ecosystem Community Group was launched right after this discussion, and the incubation of MiniApp specifications started.

During virtual TPAC 2020, there was a breakout session titled Learning from Mini Apps at the event. In this breakout session, experts discussed the abstract form of a MiniApp and the powerful features that MiniApps can have. Also, the session shared how one could build a MiniApp via various development tools. Then there was an open discussion focused on what Web developers can learn from MiniApp and their developer experience.

7.2 MiniApp in CJK

MiniApp product forms and technologies in Asian markets share lots of similarities. To gather the global community, especially the Chinese, Japanese and Korean participants, to communicate around the MiniApp ecosystem in each area and discuss the future of standardization efforts on MiniApps, W3C MiniApps Working Group, and MiniApps Ecosystem Community Group organized the 1st CJK Meeting on MiniApps in April 2021. About 90 participants from over 30 organizations joined the discussion and exchanged ideas about MiniApp ecosystems, technical architecture, frameworks and MiniApps in new scenarios such as MiniApp for vehicles. A rough conclusion about the discussion is that as the development of MiniApp standards go on well in the MiniApps Working Group, it’s time to start the horizontal review of security, privacy, accessibility as well as internationalization of MiniApp standards; also, leveraging IoT technologies in MiniApp can be a very promising direction for the for MiniApp in new scenarios and there will be good opportunity for the global MiniApp community to cooperate on the related standardization work.

7.3 MiniApps in Europe

Although there are only a few cases of MiniApps in Europe, this concept is gaining traction; and the community has started to explore these technologies, looking for new business models and innovations out of the traditional app marketplaces.

In 2021, a group of stakeholders, including three W3C Members, launched the Quick App Initiative, an open-source-oriented interest group open to any organization and individual and driven by open collaboration. This group, hosted by OW2, an independent non-profit organization based in France, is ruled under a transparent process intending to promote the W3C works from a vendor-neutral perspective and focused on outreach, implementations, and standardization requirements gathering from the European market perspective.

8. Way Forward in W3C

To meet the use cases and requirements of MiniApps, make the Web standards better support the MiniApp, explore the innovation of user agents, and enrich the Web, we hope to set up a group and include the following work in W3C:

In detail, the following technical work shall be studied further:

Note: the further gap between current MiniApp APIs and Web APIs will be analyzed in parallel.

9. Glossary

Chinese English Definition
小程序 Mini Program One format of MiniApp running within native apps.
快应用 Quick App A MiniApp standard developed by 12 mobile phone manufacturers in Quick App alliances.
渲染环境 rendering view Native view or WebView.
智能助理(负一屏) smart assistant A smart assistant to provide service for convenience, usually at left of the home screen.
热更新 hot reload No need to be re-installed when fixing or updating feature. In MiniApps, since a part of framework is implemented in JavaScript, MiniApp runtime can be hot reloaded.

A. Gap Analysis

Please look at the comparison table of APIs in MiniApps, W3C specs, and PWAs.

B. Acknowledgments

Many thanks to Guanyu Liu (360), He Du (Xiaomi), Hongguang Dong (Xiaomi), Xiaoqian Wu (W3C), Yi Shen (Baidu), Yefeng Xia (China Mobile) who also contributed to this document.

C. References

C.1 Informative references

[APPMANIFEST]
Web Application Manifest. Marcos Caceres; Kenneth Christiansen; Matt Giuca; Aaron Gustafson; Daniel Murphy; Anssi Kostiainen. W3C. 17 February 2022. W3C Working Draft. URL: https://www.w3.org/TR/appmanifest/
[MANIFEST-APP-INFO]
Web App Manifest - Application Information. Aaron Gustafson. W3C. 30 September 2021. W3C Working Group Note. URL: https://www.w3.org/TR/manifest-app-info/
[MINIAPP-ADDRESSING]
MiniApp Addressing. Dan Zhou; Qian Liu; shuo wang; Tengyuan Zhang. W3C. 11 March 2022. W3C Working Group Note. URL: https://www.w3.org/TR/miniapp-addressing/
[MINIAPP-LIFECYCLE]
MiniApp Lifecycle. Qing An; Haoyang Xu. W3C. 24 March 2022. W3C Working Draft. URL: https://www.w3.org/TR/miniapp-lifecycle/
[MINIAPP-MANIFEST]
MiniApp Manifest. Martin Alvarez-Espinar; Yongjing ZHANG. W3C. 24 March 2022. W3C Working Draft. URL: https://www.w3.org/TR/miniapp-manifest/
[MINIAPP-PACKAGING]
MiniApp Packaging. Martin Alvarez-Espinar; Qing An; Tengyuan Zhang; Yongjing ZHANG; Dan Zhou. W3C. 24 March 2022. W3C Working Draft. URL: https://www.w3.org/TR/miniapp-packaging/
[MINIAPP-WIDGET-REQ]
MiniApp Widget Requirements. Chen Yinli; Canfeng Chen; Bingqing Zhou; Bin Guo. W3C. 8 March 2022. W3C Working Group Note. URL: https://www.w3.org/TR/miniapp-widget-req/