MiniApp Manifest

W3C Working Draft

More details about this document
This version:
https://www.w3.org/TR/2022/WD-miniapp-manifest-20220517/
Latest published version:
https://www.w3.org/TR/miniapp-manifest/
Latest editor's draft:
https://w3c.github.io/miniapp-manifest/
History:
https://www.w3.org/standards/history/miniapp-manifest
Commit history
Editors:
Martin Alvarez-Espinar (Huawei)
Yongjing Zhang (Huawei)
Former editors:
Shouren Lan (Huawei)
Zhiqiang Yu (Huawei)
Xiaofeng Zhang (Huawei)
Feedback:
GitHub w3c/miniapp-manifest (pull requests, new issue, open issues)

Abstract

This specification is a registry of supplementary members for the Web Application Manifest and the Web App Manifest - Application Information specifications that provide additional metadata to an application manifest to describe MiniApps. This JSON-based manifest file enables developers to set up basic information of a MiniApp, like identification, human-readable description, versioning data, and styling information. The MiniApp manifest also configures the routing of the pages and widgets that are part of a MiniApp.

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 Working Draft using the Recommendation track.

Publication as a Working Draft does not imply endorsement by W3C and 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.

This document was produced by a group operating under the W3C Patent Policy. 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 2 November 2021 W3C Process Document.

1. MiniApp Manifest

A MiniApp manifest is a [JSON] document that extends and profiles the Web App Manifest [APPMANIFEST] and the Web App Manifest - Application Information [MANIFEST-APP-INFO], to describe metadata associated with a MiniApp.

1.1 Conformance

A MiniApp manifest MUST contain the following members at its root:

Each image resource object within the MiniApp manifest's icons member MUST contain:

A MiniApp manifest MAY contain a widgets member at its root. This member MUST contain an array (list) of MiniApp widget resources. Each MiniApp widget resource object MUST contain the following members:

A MiniApp manifest MAY contain a req_permissions member at its root. This member MUST contain an array (list) of MiniApp permission resources. Each MiniApp permission resource object MUST contain the following member:

MiniApp user agents MAY implement vendor-specific extensions of the manifest, supporting optional members.

1.2 Summary of Members

The following table shows a summary of the MiniApp manifest's members:

Members at root
Member Type Required Description
app_id string Yes MiniApp identifier
color_scheme string No MiniApp color scheme
description string No MiniApp description
device_type list No Supporting devices
dir string No Direction of texts
icons image resource list Yes MiniApp icons
lang string No MiniApp primary language
name string Yes MiniApp name
pages list Yes Page routing information
platform_version platform version resource Yes Platform version supported
req_permissions permission resource list No Required permissions
short_name string No MiniApp short name
version version resource Yes MiniApp version
widgets widget resource list No MiniApp widgets
window window resource No Window style
Members of image resource objects
(icons list)
Member Type Required Description
label string No Accessible text
sizes string No Resolution sizes of an icon
src string Yes Source of an icon
Members of platform version resource objects
(platform_version ordered map)
Member Type Required Description
min_code number Yes Minimum platform version supported
release_type string No Target platform version type
target_code string No Target platform version code
Members of permission resource objects
(req_permissions list)
Member Type Required Description
name string Yes Permission name
reason string No Reason to request the permission
Members of version resource objects
(version ordered map)
Member Type Required Description
code number Yes Version code
name string Yes Version name
Members of widget resource objects
(widgets list)
Member Type Required Description
min_code number No Minimum platform version supported
name string Yes Widget name
path string Yes Widget path
Members of window resource objects
(window ordered map)
Member Type Required Description
auto_design_width boolean No Enables/disables auto-calculation of page's design_width
background_color string No Window background color
background_text_style string No Background text style
design_width number No The baseline page design width
enable_pull_down_refresh boolean No Enable pull-to-refresh event
fullscreen boolean No Full screen display
navigation_bar_background_color string No Navigation bar background color
navigation_bar_text_style string No Text style of the navigation bar
navigation_bar_title_text string No Navigation bar title
navigation_style string No Navigation bar style
on_reach_bottom_distance number No Distance for pull-up bottom event triggering
orientation string No Screen orientation settings
Note

Other application manifest members such as scope, theme_color, related_applications, prefer_related_applications, and shortcuts are not currently supported by MiniApp user agents.

1.3 Example

This section is non-normative.

The following code represents a MiniApp manifest example:

Example 1: Manifest document
{
  "dir": "ltr",
  "lang": "en-US",
  "app_id": "org.example.miniapp",
  "name": "MiniApp Demo",
  "short_name": "MiniApp",
  "version": {
    "name": "1.0.1",
    "code": 11
  },
  "description": "A Simple MiniApp Demo",
  "icons": [
    {
      "label": "Red lightning",
      "src": "common/icons/icon.png",
      "sizes": "48x48"
    }
  ],
  "platform_version":{
    "min_code": 1,
    "release_type": "Beta1",
    "target_code": 2
  },
  "pages": [
    "pages/index/index",
    "pages/detail/detail"
  ],
  "window": {
    "background_color": "#ffffff",
    "fullscreen": false,            
    "navigation_bar_text_style": "black",
    "navigation_bar_title_text": "My MiniApp",
    "navigation_bar_background_color": "#f8f8f8"
  },
  "widgets": [
    {
      "name": "widget",
      "min_code": "2",
      "path": "widgets/index/index"
    }
  ],
  "req_permissions": [
    {
      "name": "system.permission.LOCATION",
      "reason": "To show user's position on the map"
    },
    {
      "name": "system.permission.CAMERA",
      "reason": "To scan a QR code"
    }
  ],
  "color_scheme": "light",
  "device_type": [
     "phone",
     "tv",
     "car"
  ]		  
}

1.4 Web Application Manifest members

The MiniApp manifest uses the following essential application manifest's members.

1.4.1 dir member

The MiniApp manifest's dir member, while specifying the base direction of the localizable members of the manifest, also specifies the default base text direction of the whole MiniApp.

The dir member's value can be set to one of the text-directions as specified in [APPMANIFEST]. The text-direction values are the following:

"ltr"
Left-to-right text.
"rtl"
Right-to-left text.
"auto" (default)
No explicit directionality.
Note: Processing the `dir` member

When processing a MiniApp manifest, the process the dir member algorithm is used to process the dir member, according to the [APPMANIFEST] specification.

1.4.2 icons member

The MiniApp manifest's icons member describes images that serve as iconic representations of MiniApps. This member is a list of image resource ordered maps.

As specified in [IMAGE-RESOURCE], an image resource consists of:

label
An optional string representing the accessible name of the image.
sizes
An optional string representing the sizes of the image, expressed using the same syntax as link's sizes attribute.
src
A URL from where to obtain the image data.
Note: Processing the `icons` member

When processing a MiniApp manifest, the process image resources algorithm is used to process the icons member, according to the [APPMANIFEST] specification.

Note: Accessibility considerations

Developers are strongly encouraged to add a label unless the image resource’s accessible name can be inferred from an external label in its context.

1.4.3 lang member

The MiniApp manifest's lang member, while specifying the primary language of the localizable members, also specifies the primary language of the whole MiniApp. This member is a string in the form of a language tag, a string that matches the production of a Language-Tag [BCP47], as defined in [APPMANIFEST].

Note: Processing the `lang` member

When processing a MiniApp manifest, the process the lang member algorithm is used to process the lang member, according to the [APPMANIFEST] specification.

1.4.4 name member

The MiniApp manifest's name member is the descriptive name of the application. This is the name directly displayed to the user. It is used as the display name of MiniApp along with the desktop icon and in the context of MiniApp management.

Note: Processing the `name` member

When processing a MiniApp manifest, the process a text member algorithm is used to process the name member, according to the [APPMANIFEST] specification.

1.4.5 short_name member

The MiniApp manifest's short_name member provides a concise and easy-to-read name for a MiniApp. It can be used when there is insufficient space to display the full MiniApp name provided in name.

Note: Processing the `short_name` member

When processing a MiniApp manifest, the process a text member algorithm is used to process the short_name member, according to the [APPMANIFEST] specification.

1.5 Application Information members

The following member is defined in the Web App Manifest - Application Information specification [MANIFEST-APP-INFO].

1.5.1 description member

The MiniApp manifest's description member provides a textual description for the MiniApp representing the purpose of the web application in natural language, as defined in [MANIFEST-APP-INFO]

To process the description member, given ordered map json and ordered map manifest:

  1. If json["description"] is not a string, return.
  2. Set manifest["description"] to json["description"].

1.6 Supplementary members

The following members are defined under the scope of the MiniApp manifest, addressing specific aspects of MiniApp.

1.6.1 app_id member

The MiniApp manifest's app_id member is a string that identifies the MiniApp univocally. This member is mainly used for package management, and it supports the update and release process of MiniApp versioning.

The format of app_id is RECOMMENDED to be a string defined by the following rule:

appIdRule = name *("." name)
name = ALPHA [*( ALPHA / DIGIT / "-" ) ( ALPHA / DIGIT)]
Note: Usage

One common practice is to use the reverse-domain-name-like convention (e.g., org.example.miniapp).

To process the app_id member, given ordered map json and ordered map manifest:

  1. If json["app_id"] does not exist, or if json["app_id"] is not a string, return.
  2. Set manifest["app_id"] to json["app_id"].

1.6.2 color_scheme member

The optional MiniApp manifest's color_scheme member is a string that indicates the preferred color scheme of a MiniApp (i.e., "auto", "light, or "dark"), overriding other configuration members of the window resource object, including background_color, background_text_style, navigation_bar_text_style, and navigation_bar_title_text.

This member MUST contain one of the following color scheme values:

"auto"
The theme color is adapted to the system theme color.
"light"
For a light color scheme.
"dark"
For a dark color scheme.
Note: Usage

MiniApp user agents MAY implement pre-defined styling resources, such as background colors, cover images, and icons for each color scheme. Also, developers MAY define customized stylesheets for each mode, using the prefers-color-scheme CSS media feature [MEDIAQUERIES-5].

To process the color_scheme member, given ordered map json and ordered map manifest:

  1. If json["color_scheme"] does not exist,
    or if json["color_scheme"] is not a string,
    or if json["color_scheme"] doesn't match one of the color scheme values, return.
  2. Set manifest["color_scheme"] to json["color_scheme"].

1.6.3 device_type member

The optional MiniApp manifest's device_type member is a list of strings that indicates the type of devices on which the MiniApp is intended to run. The values of this member inform user agents if the MiniApp has been designed to properly run on specific platforms like smartphones, smart TVs, car head units, wearables, and other devices.

This member is used for device compatibility verification during the initialization process. By checking its value, the user agent decides if the MiniApp is suitable to be run on the platform in terms of compatibility of UI components, CSS support, and APIs. MiniApp user agents decide how to implement the platform's behavior if the verification process fails (e.g., stopping the initialization phase and refusing the installation or installing the MiniApp but rejecting the execution).

Note: Usage

The list of possible values of the member is not specified in this document, enabling flexibility in the implementation and considering any device and use case. Some of the common values are: smartphone, tablet, tv, car, wearable, and iot.

To process the device_type member, given ordered map json and ordered map manifest:

  1. If json["device_type"] does not exist, or if json["device_type"] is not a list, return.
  2. Let device_type be a new empty list.
  3. For each item of json["device_type"]:
    1. If item is not a string, return.
    2. Append item to device_type.
  4. Set manifest["device_type"] to device_type.

1.6.4 pages member

The MiniApp manifest's pages member is a list of relative-url string used for specifying the collection of pages that are part of a MiniApp. Each item in the list represents a page identified by its page route.

A MiniApp page route is the relative path and filename of a MiniApp page. When configuring the page routes, developers MAY omit the extension of the file that defines the main component of the page (e.g., pages/mypage or pages/mypage.html).

The first item in the pages list defines the homepage or entry point of a MiniApp.

Note: Usage

For compatibility with the Web platform, it is RECOMMENDED to use pages along with the Web application manifest's start_url and scope members. These members will be set with the following values:

  • start_url SHOULD be set with the same value of the first item in the pages member; and
  • scope SHOULD be set with the value ".".

To process the pages member, given ordered map json and ordered map manifest:

  1. If json["pages"] does not exist, or if json["pages"] is not a list, return.
  2. Let pages be a new list.
  3. For each item of json["pages"]:
    1. If item is not a string, return.
    2. Let url be the result of parsing item.
    3. If url is failure, continue.
    4. Append pages to url.
  4. Set manifest["pages"] to pages.

1.6.5 platform_version member

The MiniApp manifest's platform_version member contains a MiniApp platform version resource ordered map for describing the minimum requirements and intended platform version to run a MiniApp, including min_code, target_code, and release_type.

To process the platform_version member, given ordered map json and ordered map manifest:

  1. If json["platform_version"] does not exist, or if json["platform_version"] is not an ordered map, return.
  2. Let platform_version be a new ordered map.
  3. Process the platform version's min_code member passing json["platform_version"] and platform_version.
  4. Process the platform version's target_code member passing json["platform_version"] and platform_version.
  5. Process the platform version's release_type member passing json["platform_version"] and platform_version.
  6. If platform_version["min_code"] does not exist, return failure.
  7. Set manifest["platform_version"] to platform_version.

1.6.6 req_permissions member

The optional MiniApp manifest's req_permissions member is a list of MiniApp permission resources ordered map.

Each MiniApp permission resource declares a request for using a concrete system feature (e.g., access to device's location, user contacts, sensors, and camera) required for the proper execution of a MiniApp.

To process the req_permissions member, given ordered map json and ordered map manifest:

  1. If json["req_permissions"] does not exist, or if json["req_permissions"] is not a list, return.
  2. Let permissions be a new list.
  3. For each item of json["req_permissions"]:
    1. If item is not an ordered map, continue.
    2. Let permission be an ordered map.
    3. Process the permission resource's name member passing item and permission.
    4. If permission["name"] does not exist, continue.
    5. Process the permission resource's reason member passing item and permission.
    6. Append permission to permissions.
  4. Set manifest["req_permissions"] to permissions.
Note: Protection of user's privacy

User agents will ask for the user's consent to protect their privacy during access to these specific features. This information in the req_permissions member may be used by app stores or hosting platforms to filter MiniApps according to the user's preferences, privacy policy, or device capabilities.

1.6.7 version member

The MiniApp manifest's version member contains a MiniApp version resource ordered map to represent the code and name.

To process the version member, given ordered map json and ordered map manifest:

  1. If json["version"] does not exist, or if json["version"] is not ordered map, return.
  2. Let version be a new ordered map.
  3. Process the version's code member passing json["version"] and version.
  4. Process the version's name member passing json["version"] and version.
  5. Set manifest["version"] to version.

1.6.8 widgets member

The optional MiniApp manifest's widgets member is a list of MiniApp widget resources that are a part of a MiniApp.

A MiniApp Package MAY include MiniApp pages and Widgets concurrently.

A widget, as part of a MiniApp, applies some of the members of the MiniApp manifest, including:

However, a widget also has its exclusive fields as defined in the MiniApp widget resource.

To process the widgets member, given ordered map json and ordered map manifest:

  1. If json["widgets"] does not exist, or if json["widgets"] is not a list, return.
  2. Let widgets be a new empty list.
  3. For each item of json["widgets"]:
    1. If item is not an ordered map, continue.
    2. Let widget be an ordered map.
    3. Process the widget's name member passing item and widget.
    4. Process the widget's path member passing item and widget.
    5. Process the widget's min_code member passing item, manifest, and widget.
    6. If widget["name"] does not exist, or if item["path"] does not exist, continue.
    7. Append widget to widgets.
  4. Set manifest["widgets"] to widgets.

1.6.9 window member

The optional MiniApp manifest's window member contains a MiniApp window resource ordered map to describe the look and feel of a MiniApp frame, including the styles of the status bar, navigation bar, title, background colors, among other visual configuration elements.

The window object members inherit the text direction and language configuration from the dir and lang members at the root of the MiniApp manifest.

To process the window member, given ordered map json and ordered map manifest:

  1. If json["window"] does not exist, or if json["window"] is not an ordered map, return.
  2. Let window be a new ordered map «[ "auto_design_width" → false, "background_color" → "#ffffff", "background_text_style" → "dark", "design_width" → 750, "enable_pull_down_refresh" → false, "fullscreen" → "false", "navigation_bar_background_color" → "#000000", "navigation_bar_text_style" → "white", "navigation_bar_title_text" → "default", "on_reach_bottom_distance" → 50, "orientation" → "portrait" ]».
  3. Process the window's auto_design_width member passing json["window"] and window.
  4. Process a color member passing json["window"], window and "background_color".
  5. Process the window's background_text_style member passing json["window"] and window.
  6. Process the window's design_width member passing json["window"] and window
  7. Process the window's enable_pull_down_refresh member passing json["window"] and window.
  8. Process the window's fullscreen member passing json["window"] and window.
  9. Process a color member passing json["window"], window and "navigation_bar_background_color".
  10. Process the window's navigation_bar_text_style member passing json["window"] and window.
  11. Process the window's navigation_bar_title_text member passing json["window"] and window.
  12. Process the window's navigation_style member passing json["window"] and window.
  13. Process the window's on_reach_bottom_distance member passing json["window"] and window.
  14. Process the window's orientation member passing json["window"] and window.
  15. Process the window's auto_design_width member passing json["window"] and window.
  16. Set manifest["window"] to window.

1.7 Processing the manifest

The MiniApp manifest, as an extension of the Application manifest, provides a supplementary algorithm to be processed at the extension point of the processing a manifest algorithm defined in [APPMANIFEST]. Thus, the user agent starts by processing the Application manifest's members and, at the extension point, continues with processing the MiniApp manifest members using the following algorithm.

To process a MiniApp manifest at the extension point, given ordered map json and ordered map manifest:

  1. If manifest["name"] does not exist, throw a TypeError.
  2. If manifest["icons"] does not exist, throw a TypeError.
  3. Let icons be manifest["icons"].
  4. If icons["src"] does not exist, throw a TypeError.
  5. If manifest["icons"] does not exist, throw a TypeError.
  6. Process the app_id member passing json and manifest.
  7. If manifest["app_id"] does not exist, throw a TypeError.
  8. Process the color_scheme member passing json and manifest.
  9. Process the description member passing json and manifest.
  10. Process the device_type member passing json and manifest.
  11. Process the pages member passing json and manifest.
  12. If manifest["pages"] does not exist, throw a TypeError.
  13. Process the platform_version member passing json and manifest.
  14. If manifest["platform_version"] does not exist, throw a TypeError.
  15. Process the req_permissions member passing json and manifest.
  16. Process the version member passing json and manifest.
  17. If manifest["version"] does not exist, throw a TypeError.
  18. Process the widgets member passing json and manifest.
  19. Process the window member passing json and manifest.

2. MiniApp platform version resources

A MiniApp platform version resource is an ordered map that indicates the minimum and target platform versions to be used by the MiniApp.

The following members are defined under the scope of the MiniApp manifest, addressing specific aspects of a platform version resource.

2.1 min_code member

The MiniApp platform version resource's min_code member is a non-negative integer number that indicates the minimum supported version of the MiniApp user agent's platform to ensure the regular operation of a MiniApp.

To process the platform version's min_code member, given ordered map json and ordered map platform_version:

  1. If json["min_code"] does not exist, or if json["min_code"] is not a number, return failure.
  2. Set platform_version["min_code"] to json["min_code"].

2.2 release_type member

The MiniApp platform version resource's release_type member is a string that indicates the release type of the MiniApp user agent's target platform version that is required for running an application.

Note: Usage

MiniApp vendors may recommend specific versioning schemes and values for this member (e.g., CanaryN, BetaN, or Release, where N represents a positive integer, such as Beta1).

To process the platform version's release_type member, given ordered map json and ordered map platform_version:

  1. If json["release_type"] does not exist, or if json["release_type"] is not a string, return.
  2. Set platform_version["release_type"] to json["release_type"].

2.3 target_code member

The MiniApp platform version resource's target_code member is a non-negative integer number that indicates the target supported version of the MiniApp user agent's platform to ensure the regular operation of a MiniApp.

To process the platform version's target_code member, given ordered map json and ordered map platform_version:

  1. If json["target_code"] does not exist, or if json["target_code"] is not a number, return.
  2. Set platform_version["target_code"] to json["target_code"].

3. MiniApp permission resources

A MiniApp permission resource is an ordered map that describes a request for using a concrete system feature (e.g., access to device's location, user contacts, sensors, and camera) required for the proper execution of a MiniApp.

The following members are defined under the scope of the MiniApp manifest, addressing specific aspects of a permission resource.

3.1 name member

The MiniApp permission resource's name member is a string that indicates the name of the feature requested.

To process the permission resource's name member, given ordered map json and ordered map permission:

  1. If json["name"] does not exist, or
    if json["name"] is not a string, or if json["name"] is the empty string, return.
  2. Set permission["name"] to json["name"].

3.2 reason member

The optional MiniApp permission resource's reason member is a string that indicates the reason given to request the feature specified in the [MiniApp permission resource/name=] attribute.

To process the permission resource's reason member, given ordered map json and ordered map permission:

  1. If json["reason"] does not exist, or
    if json["reason"] is not a string, or if json["reason"] is the empty string, return.
  2. Set permission["reason"] to json["reason"].

4. MiniApp version resources

A MiniApp version resource is an ordered map that describes the version code and version name of a MiniApp.

The following members are defined under the scope of the MiniApp manifest, addressing specific aspects of a version resource.

4.1 code member

The MiniApp version resource's code member is a non-negative integer number that represents the version of a MiniApp. It is mainly used for enhancing the maintainability and security of MiniApp (e.g., compatibility among incremental versions). The code member aims at supporting the development and deployment process, and it is not usually displayed to the end-user.

To process the version's code member, given ordered map json and ordered map version:

  1. If json["code"] does not exist, or if json["code"] is not a number, return failure.
  2. Let version be a number, initially 1.
  3. If json["code"] is greater than 0, then:
    Set version to json["code"].
  4. Set version["code"] to version.

4.2 name member

The MiniApp version resource's name member is a string mainly used for describing information on the version of a MiniApp, playing an essential role in version control, MiniApp application, and platform compatibility. It is usually considered as the version that is shown publicly and displayed to the user.

Note: Usage

The RECOMMENDED format for this member is X.Y.Z, where X, Y, and Z are non-negative integer values (e.g., 1.10.0), as specified in Semantic Versioning [SEMANTIC-VERSIONING].

To process the version's name member, given ordered map json and ordered map version:

  1. If json["name"] does not exist, or if json["name"] is not a string, return failure.
  2. Set version["name"] to json["name"].

5. MiniApp widget resource members

A MiniApp widget resource is an ordered map that defines and configures a widget that is part of a MiniApp.

The following members are defined under the scope of the MiniApp manifest, addressing specific aspects of a widget resource.

5.1 name member

The MiniApp widget resource's name member is a string that indicates the title of a widget.

To process the widget's name member, given ordered map json and ordered map widget:

  1. If json["name"] does not exist, or if json["name"] is not a string, return.
  2. Set widget["name"] to json["name"].

5.2 path member

The MiniApp widget resource's path member is a relative-url string that defines the corresponding page route of a widget, represented as in the pages list.

To process the widget's path member, given ordered map json and ordered map widget:

  1. If json["path"] does not exist, or if json["path"] is not a string, return.
  2. Let url be the result of parsing json["path"].
  3. If url is failure, return.
  4. Set widget["path"] to url.

5.3 min_code member

The optional MiniApp widget resource's min_code member is a number that indicates the minimum platform version supported for a MiniApp widget.

Note: Usage

Since Widget APIs and MiniApp APIs may differ, the declaration of the minimum version of the platform may be different. Thus, if the widgets member omits min_code explicitly, the user agent will consider the same requirement as the specified in the min_code member in the platform_version object.

To process the widget's min_code member, given ordered map json, ordered map widget and ordered map manifest:

  1. Set widget["min_code"] to manifest["min_code"].
  2. If json["min_code"] does not exist, or if json["min_code"] is not a string, return.
  3. Set widget["min_code"] to json["min_code"].

6. MiniApp window resource members

A MiniApp window resource is an ordered map that defines and configures the window that contains a MiniApp.

The following members are defined under the scope of the MiniApp manifest, enabling the description of a MiniApp window resource.

6.1 auto_design_width member

The auto_design_width member is a boolean that indicates whether the design_width of the page is auto-calculated by the user agent. When auto_design_width is true, the value of design_width is ignored. In this case, the system's baseline width is automatically determined according to the pixel density of the screen.

Value by default: false.

To process the window's auto_design_width member, given ordered map json and ordered map window:

  1. If json["auto_design_width"] does not exist, or if json["auto_design_width"] is not a boolean, return.
  2. Set window["auto_design_width"] to json["auto_design_width"].

6.2 background_color member

The background_color member is a string that specifies the background color of the window that contains a MiniApp.

This member supports sRGB colors, and it is equivalent to the application manifest's background_color.

Value by default: "#ffffff".

Note: Processing the `background_color` member

When processing a MiniApp manifest, the process a color member algorithm is used to process the window's background_color member, according to the [APPMANIFEST] specification.

6.3 background_text_style member

The background_text_style member is a string that specifies the background text style, indicating a light or dark color theme (i.e., "light" or "dark").

This member supports the values of prefers-color-scheme and MUST contain one of the following background text style values:

"light"
For light style.
"dark" (default)
For dark style.

To process the window's background_text_style member, given ordered map json and ordered map window:

  1. If json["background_text_style"] does not exist, or
    if json["background_text_style"] is not a string, or
    if json["background_text_style"] doesn't contain one of the background text style values, return.
  2. Set window["background_text_style"] to json["background_text_style"].

6.4 design_width member

The design_width member is a number that indicates the baseline width of the page design in pixel unit. It is used for visually adjusting the page components.

The value is a non-negative integer and the value by default is 750.

To process the window's design_width member, given ordered map json and ordered map window:

  1. If json["design_width"] does not exist, or
    if json["design_width"] is not a number, or if json["design_width"] is less than 0, return.
  2. Set window["design_width"] to json["design_width"].

6.5 enable_pull_down_refresh member

The enable_pull_down_refresh member is a boolean that specifies if the pull-to-refresh event is enabled during the interaction with the MiniApp.

Value by default: false.

To process the window's enable_pull_down_refresh member, given ordered map json and ordered map window:

  1. If json["enable_pull_down_refresh"] does not exist,
    or if json["enable_pull_down_refresh"] is not a boolean, return.
  2. Set window["enable_pull_down_refresh"] to json["enable_pull_down_refresh"].

6.6 fullscreen member

The fullscreen member is a boolean that indicates if the MiniApp is shown in full-screen display mode.

Note: Usage

When this member takes the true value, it is equivalent to the fullscreen value on the application manifest's display member. When it takes false as value, it is equivalent to minimal-ui.

Value by default: false.

To process the window's fullscreen member, given ordered map json and ordered map window:

  1. If json["fullscreen"] does not exist,
    or if json["fullscreen"] is not a boolean, return.
  2. Set window["fullscreen"] to json["fullscreen"].

6.11 on_reach_bottom_distance member

The on_reach_bottom_distance member is a number that defines the vertical offset from the bottom of the window required to trigger a page pull-up event. Values for this member are non-negative integers expressed in pixel unit.

Value by default: 50.

To process the window's on_reach_bottom_distance member, given ordered map json and ordered map window:

  1. If json["on_reach_bottom_distance"] does not exist, or
    if json["on_reach_bottom_distance"] is not a number, or
    if json["on_reach_bottom_distance"] is less than 0, return.
  2. Set window["on_reach_bottom_distance"] to json["on_reach_bottom_distance"].

6.12 orientation member

The orientation member is a string that specifies the configuration of the screen orientation for the MiniApp.

This member supports the orientation values: "portrait" and "landscape" defined in OrientationLockType [SCREEN-ORIENTATION].

Note: Usage

This member is equivalent to the application manifest's orientation.

Value by default: "portrait".

To process the window's orientation member, given ordered map json and ordered map window:

  1. If json["orientation"] does not exist, or
    if json["orientation"] is not a string, or
    if json["orientation"] doesn't contain one of the orientation values, return.
  2. Set window["orientation"] to json["orientation"].

7. Localizable members

A localizable member is a manifest member whose content may be adapted to specific linguistic, geographical, and cultural aspects. These localizable members share the language tag (lang) and display direction (dir) defined at manifest's root.

The following members are localizable members:

8. Dependencies

As a crucial part of a MiniApp Package, the manifest.json file describes several important aspects of a MiniApp by referring to the MiniApp Package resources in different file types, such as the page scripts and visual configuration files in the pages directory and the images in the common directory. Details are specified in [MINIAPP-PACKAGING].

The regular operation of a MiniApp relies on the proper configuration in the manifest and the MiniApp Package availability of resources. Such dependency needs to be checked during both the development phase and deployment phase.

9. Accessibility considerations

This section is non-normative.

This document specifies a set of metadata, enabling developers and publishers to describe and configure the behavior and appearance of MiniApps. Some manifest attributes, like color_scheme and the window resource members, aim user agents to generate customized user interfaces to enable interaction between the user and the MiniApp.

The icons member allows developers to describe the visual and iconic representation of a MiniApp in the platform and operating system. Here, the platform should adequately communicate with the platform accessibility services to represent the images, also using the alternative textual descriptions (e.g., icon's label, name and short_name) to enhance accessibility (i.e., icons in the home screen of the device, listing in app directories, and app configuration).

User agents must ensure that the user interface is perceivable and operable, so they should take special consideration when processing the members that affect the user agent interface and the rendered content, like with the setup of color schemes and themes (i.e., color_scheme, background_color, background_text_style, navigation_bar_background_color, navigation_bar_background_color, navigation_bar_text_style, and navigation_style) and other configuration settings like orientation, fullscreen, enable_pull_down_refresh, and on_reach_bottom_distance.

The manifest's window member defines the appearance of the MiniApp, including the look and feel of the navigation bar and other features that modify the user agent's native UI, like fullscreen or orientation. User agents must offer intuitive mechanisms to close the apps, reverting the changes that affected the native UI.

User agents interpreting this manifest should help users orient within and control windows and viewports. They should also provide alternative views addressing the different usage scenarios through the advanced use of the device_type member and extending the manifest with vendor-specific members to enhance accessibility. Thus, MiniApp user agents and platforms should provide mechanisms for configuring user stylesheets, themes and customize the display and interaction with the application, complying with the applicable specifications and conventions, in particular the User Agent Accessibility Guidelines (UAAG) 2.0.

10. Security considerations

The manifest data helps platforms to configure and process applications properly. The information exposed by the document is public, so third-party agents (e.g., app marketplaces and repositories) may use the manifest information to maintain app versions, classify, and list them.

As the manifest is a JSON document and will commonly be encoded using [UNICODE], the security considerations described in [JSON] and [UNICODE-SECURITY] apply. In order to prevent developers from including custom/unrestrained data in a manifest, implementors may use a more strict schema than that defined in JSON Schema to impose their implementation-specific limits on the member names, types, and value ranges (e.g., to guard against memory overflow, or to meet platform-specific limitations).

The integrity of the MiniApp resources, including the manifest, is protected by a cryptographic hash mechanism as part of the whole MiniApp Package, as detailed in [MINIAPP-PACKAGING].

A MiniApp contains different file resources organized in directories within a container. Manifest members like icons, pages, and widgets contain paths referring to local resources on the hosting platform. MiniApp user agents MUST guarantee the sandboxed environment, checking the validity of those paths to prevent illegal access out of a MiniApp package.

Developers may access external MiniApp data resources (i.e., not included in the main package) on the hosting platform (e.g., deep-links to other applications and shared storages) or remote HTTP servers. In the former case, the MiniApp user agent should implement all the required mechanisms to guarantee the sandboxed environment on the platform.

The pages member defines the routes of the components of a MiniApp, including a map of pages with a relative path referring to resources stored within the MiniApp container. User agents MUST ignore external URLs or paths that do not correspond to a valid resource in the MiniApp container.

The manifest specifies the features that could be requested during the operation of a MiniApp, involving access to sensors and communication with other devices, both via network connections and via direct connection to the device (e.g., via Bluetooth, NFC, or USB). The declaration does not imply the access and use of the feature. However, user agents MUST implement mechanisms to guarantee the correct usage of services and APIs and address the potential vulnerabilities in each concrete feature.

11. Privacy considerations

This specification does not directly deal with sensitive data. However, the information defined in a MiniApp manifest helps the platform configure its privacy policies to let a MiniApp manage other devices' hardware, software, and data resources that could affect privacy.

The MiniApp manifest does not motivate collecting, using, or disclosing personal data. However, MiniApp user agents MUST control the access to sensitive device's services and features that could contribute to fingerprinting. User's behavioral patterns in permission management, along with the device's specific constraints (i.e., MiniApps for automotive, IoT, and SmartTVs), could allow users to be fingerprinted. For this reason, MiniApp user agents MUST control the access to the device's resources and preserve the sandboxed environment, protecting the access to sensitive resources, such as device sensors, external software, and personal data, with no disclosure of user's preferences.

Through the manifest's req_permissions member, developers declare the requirements of a MiniApp to access privacy-related sensitive and high-level privileged resources. This member allows the platform to understand the specific restricted resources the MiniApp may request (name member), informing the user about the potential consequences and granting (or keeping blocked) access to these resources. Developers SHOULD use the reason member to state the clear and easy-to-understand rationale for requesting these advanced resources.

User agents MUST manage the user's preferences, including the explicit permissions the user shall grant to use sensitive system's features (e.g., geolocation and device's sensors). The user agent SHOULD implement mechanisms to remember their preferences, and the end-user SHALL explicitly decide if this information is stored across sessions. No other information related to the manifest should persist across sessions.

As in Web applications, MiniApps can be installed using UI dialogs. In the installation process, the user agent SHOULD display clear information about the app (i.e., app_id, name, short_name, icons, description). This transparent information allows end-users to make a conscious decision before installing it.

User agents SHOULD provide a mechanism to remove an installed MiniApp. It is RECOMMENDED that at the time of removal, the user agent also presents the user with an opportunity to revoke other persistent data and settings associated with the application, such as permissions and persistent storage.

A. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, RECOMMENDED, SHALL, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This specification uses the Augmented Backus-Naur Form (ABNF) as defined in [RFC5234].

The MiniApp Manifest specification depends on the Infra Standard [INFRA] to describe algorithms.

B. JSON Schema

Developers interested in validating the MiniApp manifest document can use the JSON Schema defined at https://w3c.github.io/miniapp-manifest/manifest_schema.json.

Note: MiniApp Manifest JSON Schema

C. Acknowledgements

This section is non-normative.

Editor's note
To include contributors here!

D. Extensibility

This section is non-normative.

This specification is based on the application manifest extensibility principle.

Although proprietary extensions are undesirable, they may be included as a manifest extension. In this case, it is RECOMMENDED to use vendor prefixes for the new members.

We encourage implementors to add proprietary extensions to the Extensions Registry. This allows the community to track what extensions vendors and/or the web community have defined and documented.

Issue 9: Proprietary extensions of the manifest

The Web App Manifest allows adding new proprietary manifest members using vendor prefixes: https://www.w3.org/TR/appmanifest/#proprietary-extensions

We probably need something similar.

The following is an example of three hypothetical vendor extensions.

Example 2: Proprietary extensions
{
  ...
  "wechat_new_feature": "foo",
  "ali_new_url_system": "http://example.org",
  "coolminiapp_menu_color": "#FA0000"
  ...
}

E. References

E.1 Normative 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/
[BCP47]
Tags for Identifying Languages. A. Phillips, Ed.; M. Davis, Ed.. IETF. September 2009. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc5646
[css-color-4]
CSS Color Module Level 4. Tab Atkins Jr.; Chris Lilley; Lea Verou. W3C. 15 December 2021. W3C Working Draft. URL: https://www.w3.org/TR/css-color-4/
[css-values]
CSS Values and Units Module Level 3. Tab Atkins Jr.; Elika Etemad. W3C. 6 June 2019. W3C Candidate Recommendation. URL: https://www.w3.org/TR/css-values-3/
[html]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[IMAGE-RESOURCE]
Image Resource. Aaron Gustafson; Rayan Kanso; Marcos Caceres. W3C. 4 June 2021. W3C Working Draft. URL: https://www.w3.org/TR/image-resource/
[INFRA]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[JSON]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. December 2017. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc8259
[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/
[MEDIAQUERIES-5]
Media Queries Level 5. Dean Jackson; Florian Rivoal; Tab Atkins Jr.; Daniel Libby. W3C. 18 December 2021. W3C Working Draft. URL: https://www.w3.org/TR/mediaqueries-5/
[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/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC5234]
Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed.; P. Overell. IETF. January 2008. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc5234
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[SCREEN-ORIENTATION]
The Screen Orientation API. Mounir Lamouri; Marcos Caceres; Johanna Herman. W3C. 6 September 2021. W3C Working Draft. URL: https://www.w3.org/TR/screen-orientation/
[UNICODE]
The Unicode Standard. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
[UNICODE-SECURITY]
Unicode Security Considerations. Mark Davis; Michel Suignard. Unicode Consortium. 19 September 2014. Unicode Technical Report #36. URL: https://www.unicode.org/reports/tr36/tr36-15.html
[url]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[webidl]
Web IDL Standard. Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/

E.2 Informative references

[mediaqueries]
Media Queries Level 4. Florian Rivoal; Tab Atkins Jr.. W3C. 25 December 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/mediaqueries-4/
[SEMANTIC-VERSIONING]
Semantic Versioning. URL: https://semver.org/
[UAAG20]
User Agent Accessibility Guidelines (UAAG) 2.0. James Allan; Greg Lowney; Kimberly Patch; Jeanne F Spellman. W3C. 15 December 2015. W3C Working Group Note. URL: https://www.w3.org/TR/UAAG20/