This document introduces a new format for mobile application, named MiniApp, which is a very popular hybrid solution relies on Web technologies but also integrates with capabilities of Native Apps.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. 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 is still a work in progress. The proposal is being incubated in the W3C Chinese Web Interest Group.
This document was published by the Chinese Web Interest Group as a First Public Working Draft.
GitHub Issues are preferred for discussion of this specification. Alternatively, you can send comments to our mailing list. Please send them to firstname.lastname@example.org (archives).
Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. 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.
This document was produced by a group operating under the W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 March 2019 W3C Process Document.
Native Apps are well received in our daily life, but there are still many things that can be done better for users.
Before a user get the service from a native app, he/she often have to go through the process to download -> install -> register the app.
User can only keep a limited number of Native Apps on their phone due to constraint of storage capability.
It's not easy to share data between different Native apps.
To work on a Native App, developers may need to learn a few new programming languages.
To provide the same service with Native Apps, developers may need to maintain duplicate products for different platforms.
The Web is an ideal platform to avoid these problems, but by far, it's still imperfect.
Compared to the Native, it isn't easy to take advantage of the capabilities provided by the system.
Also, it's usually difficult to design a Web application whose performance can actually match or surpass a similar Native app.
On a mobile device, users obtain services or contents outside the browser very frequently, naturally, they would like all their applications to be consistent on user accounts, login status and user interaction across the whole system.
Moreover, sometimes users may want to share some data with an application if they really trust it, but for a few frequently requested information, such as personal mobile number of the current device, or the contact list, there isn't a good way for the users to give permits on the Web.
MiniApps got popular from their usage on a few super-apps, as it was born with a few characters that help to fill the gap of the Web and the Native.
MiniApps are NOT aimed to replace PWA, or the Web, or the Native.
This MiniApp tries to build an AR zoo with AI technologies to recognise the animals. Developers can easily do that by adding a few components or APIs that provide access to the native capabilities or advance features, f.ex., Image Recognition, AR 3D Animal models rendering, a speech API to for speech synthesis, AR navigation provided by the map SDK.
MiniApps can be discovered by the search engines, by the MiniApp store in the hosted-app or by QR-code.
For the developers, the incentive to work on miniapps is very obvious.
|the Web||Native App||MiniApp|
|Discoverability||Search Engine||App Store||Multiple: search engines + MiniApp store in the hosted-apps + QR-code|
|Verified/Trusted||Still exploring||by Native App stores||by host App platforms|
|Deploy/Reload||load/reload the webpage||installed/reinstalled||load/reload as it's using a JS 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|
One of the goals of MiniApp to connect information and services across different platforms, so it's ideal for IoT applications such as Smart Automotive, voice-control speaker 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 design for the vehicle system, to help distribute or upgrade applications to various of car model. 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".
In a miniapp, the view layer is usually separated from the logic layer.
The View Layer is responsible for rendering MiniApp pages, including Web components rendering and native components rendering, which can be considered as hybrid rendering. For example, Web components rendering can be handled by WebView, but some of the Web components rendering aren't supported by WebView or have performance limitation, MiniApp also relies on some native components, such as map, video, etc.
Logic Layer is implemented with JS Worker. The Worker is responsible for MiniApp’s event processing, API calling and lifecycle management.
Extended native capabilities usually come from the hosting Native App or OS, including payment, file processing, scanning, phone call, etc. These capabilities are called through certain APIs. When a Mini App calls a native API, it transfers the API calling to Extended Native Capabilities for further processing via JS Bridge, and obtains the result from Extended Native Capabilities via JS Bridge.
Worker establishes connection for each Render, transferring the need-to-be-rendered data to 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 worker for further processing. At the same time, the Render will wait for the data sent from worker to re-render the MiniApp page.
The rendering can be considered as stateless, and all the states will be stored in the worker.
The benefits of separating the View Layer and the Logic Layer include:
MiniApp platform provides many components to help developers build a fancy UI, including basic components like View, Form, Image, and high-level component like Maps.
MiniApp venders also offer a number of APIs for developers to get access to capabilities of both the Web and the native, including basic APIs such as UI display APIs, Image API, and those advanced ones like Account API, Map API, Payment API.
APIs usually work together with components. When user clicks certain component on a MiniApp page, it will call the related API to complete user’s interaction and refresh the current MiniApp page if needed.
A MiniApp package is a compressed format (e.g. zip) archive, including:
For the purpose of locating a specific MiniApp while searching and executing, a MiniApp must have a package name or an ID on the platform. An icon is also required for user recognization.
In addition to being presented in the form of an MiniApp page, MiniApp can also be displayed in the form of information fragment, that is, a MiniApp widget. In this form, developers can put their service and/or content to various host scenarios, called host environment, such as assistants, search page, etc.. This feature connects services of the MiniApp with the scenario, providing users with more convenience.
For example, when a user purchases a train ticket for trip, the MiniApp widget on 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.
Same as MiniApp page, widget is also described by URI scheme. The host environment specifies the MiniApp package and the corresponding widget to be loaded through URI path, and passes data to the widget through URI query params. 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 its 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 word, MiniApp widget and page have same data access rights.
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 on different scenarios, such as text keywords, voice analysis, picture recognition, scan code, event intent.
There are multiple entrances to discover, open and access MiniApps. Unlike Web in multi WebView, 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 a MiniApp through the entrance of QR code for the first time, the user will remain logged in next time when the user returns from another entrance like MiniApp store.
The entries for MiniApps include, but not limit to:
MiniApps try to improve their performance and user experience with a few mechanisms that have been proved to be effective through practice.
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 openning first time.
The MiniApp uses native page stack management between render views, and the page switching is driving by native code. Therefore, the gesture operation in the page, the switching between pages can achieve the exactly same smooth experience as Native.
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, then we continue to pre-built 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 exit, the runtime will be destroyed and the application environment and resources can be reused.
MiniApp platforms provides very rich components and APIs, these components and APIs are usually well designed and able to help ensure the performance of the general work from developers.
This section describes a few current mainstream MiniApp or relevant platforms.
Now there have been more than 1,000,000 Mini Programs running on Alipay Native App and 230 million DAU (Daily Active User). The user scenarios include retails, transportation, medical services, etc.
Baidu Smart Mini Program refers to an open ecological product that intelligently connects people to information and services, which based on Baidu APP and other partners’ platforms. Through Baidu’s AI abilities, and by understanding all contents in Smart Mini Programs, we connect user and Smart Mini Program accurately. With Baidu’s search and information flow dual engine, users can achieve an APP-like experience within Smart Mini Programs. As of July 2019, we have 150,000+ Smart Mini Programs and 270 million MAU.
Baidu Smart Mini Program is open-sourced within our open source alliance, which has more than 30 cooperators, covered super APPs, mobile OS, car OS, voice-control speakers and TV.
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 in 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 forms.
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 operation system.
PC miniapps are only available to those validated as an enterprise account, most of the features are under tough regulations, so that they can be considered as highly trusted web contents.
PWAs are the latest term to summarize modern web applications. As a counterpart of native apps, a PWAs app looks and feels like a native app, and can be installed to home screen / launcher / start menu; it can send push notification to re-engage user; it can be used when offline and behaves under poor network condition; it works with devices of wide ranging capabilities and it's still evolving to works with new capabilities defined by open web standards; payment can be made by user inside PWAs apps; and PWAs apps are search-engine-friendly and work perfectly with hyper-links. PWAs are successful on both the technical aspect and business aspect (widely adopted by many web sites, esp. consumer facing ones).
This section selects some typical use cases and proposes a few APIs that MiniApps would like to have support from the Web.
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 from the Native.
Proposal: Mini App needs a standardized API to help integrate the native rendering result into Web rendering result.
MiniApp would like to provide transition animation during page switching so that users can have similar experience as when they are using a Native App, but it's almost impossible to do that now.
Proposal: Mini App needs an API to call add transition animation during MiniApp page switching.
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.
Like Android widgets or apple dashboard, users can directly get information and/or finish their task by 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 desktop or dashboard.
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.
3D models become more and more popular thanks to its rich details, and combined with AR, it will provide a much 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 model. In this document, we propose to define a HTML tag to directly handle 3D model, similar to the way we handle audio, video, image with corresponding HTML tags:
User can view a 3D model from different angles via gestures. And the 3D model can be zoom in/out as well. It can be viewed in full screen, or it can be embedded in a HTML page, shown together w/ other HTML contents.
User can place the 3D model in the real world environment with camera. User can specify different locations to place the model.
<xmodel> Element to specify a 3D model on the web and to power interactive 3D contents with AR.
Face tracking can be used in many 3D scenarios.
Proposal: A Face Tracking API use a video element as input and updates face tracking output every frame, which includes:
Hand gestures can be used in video effect and AR/VR games scenario which can make apps more impressive and interactive.
Proposal: A high-level API to track hands movement, get hands outline.
There are a few AR APIs in MiniApps we would migrate to the Web, as they help to provide better AR experience in gaming, 3d model preview, interactive ads.
Proposal: Provide low-level AR APIs based on ARCore and ARKit, which includes:
MiniApp utilizes HTTPs to support secure connection. Multiple MiniApps within same host environment are independent with each other.
User interactions within MiniApp needs different level of user permissions:
|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(qr code), network status, Bluetooth, NFC|
|permission on every usage||Contacts, file-apis, add to home screen, photo picker, phone call|
|Validate with token||Push|
To meet the use cases and requirements of MiniApps, and make the Web standards better support the MiniApp, we hope to include the following work in W3C:
In details, the following technical work has been discussed:
|小程序||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|
Please look at the comparison table of APIs in MiniApps, W3C specs, and PWAs..
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.