Copyright © 2021-2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
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.
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.
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.
This specification defines the set of metadata to describe MiniApps, extending the Web Application Manifest and the Web App Manifest - Application Information by providing additional constraints and specific mechanisms to describe and set up MiniApps. The MiniApp Manifest directly reuses essential elements from these specifications (i.e., name
, short_name
, description
, and icons
), adding supplementary members that specifically affect MiniApps (e.g., app_id
, version
, platform_version
, device_type
, pages
, req_permissions
, and widgets
) and their look and feel (e.g., color_scheme
and window
).
A MiniApp manifest MUST contain the following members at its root:
Each image resource object within the MiniApp manifest's
member MUST contain:
icons
A MiniApp manifest MAY contain a
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:
widgets
A MiniApp manifest MAY contain a
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:
req_permissions
MiniApp user agents MAY implement vendor-specific extensions of the manifest, supporting optional members.
The following table shows a summary of the MiniApp manifest's members:
Member | Type | Required | Description |
---|---|---|---|
|
string | Yes | MiniApp identifier |
|
string | No | MiniApp color scheme |
|
string | No | MiniApp description |
|
list | No | Supporting devices |
|
string | No | Direction of texts |
|
image resource list | Yes | MiniApp icons |
|
string | No | MiniApp primary language |
|
string | Yes | MiniApp name |
|
list | Yes | Page routing information |
|
platform version resource | Yes | Platform version supported |
|
permission resource list | No | Required permissions |
|
string | No | MiniApp short name |
|
version resource | Yes | MiniApp version |
|
widget resource list | No | MiniApp widgets |
|
window resource | No | Window style |
Member | Type | Required | Description |
---|---|---|---|
label |
string | No | Accessible text |
sizes |
string | No | Resolution sizes of an icon |
src |
string | Yes | Source of an icon |
Member | Type | Required | Description |
---|---|---|---|
|
number | Yes | Minimum platform version supported |
|
string | No | Target platform version type |
|
string | No | Target platform version code |
Member | Type | Required | Description |
---|---|---|---|
|
string | Yes | Permission name |
|
string | No | Reason to request the permission |
Member | Type | Required | Description |
---|---|---|---|
|
number | Yes | Version code |
|
string | Yes | Version name |
Member | Type | Required | Description |
---|---|---|---|
|
number | No | Minimum platform version supported |
|
string | Yes | Widget name |
path |
string | Yes | Widget path |
Member | Type | Required | Description |
---|---|---|---|
|
boolean | No |
Enables/disables auto-calculation of page's
|
|
string | No | Window background color |
|
string | No | Background text style |
|
number | No | The baseline page design width |
|
boolean | No | Enable pull-to-refresh event |
|
boolean | No | Full screen display |
|
string | No | Navigation bar background color |
|
string | No | Text style of the navigation bar |
|
string | No | Navigation bar title |
|
string | No | Navigation bar style |
|
number | No | Distance for pull-up bottom event triggering |
|
string | No | Screen orientation settings |
Other application manifest members such as scope
,
theme_color
,
related_applications
,
prefer_related_applications
, and
shortcuts
are not currently supported by MiniApp user agents.
This section is non-normative.
The following code represents a MiniApp manifest example:
{
"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"
]
}
The MiniApp manifest uses the following essential application manifest's members.
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
member's value can be set to one of the text-directions as specified in [APPMANIFEST]. The text-direction values are the following:dir
ltr
"rtl
"auto
" (default)
When processing a MiniApp manifest, the process the dir
member algorithm is used to process the dir
member, according to the [APPMANIFEST] specification.
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
sizes
link
's sizes
attribute.
src
When processing a MiniApp manifest, the process image resources algorithm is used to process the icons
member, according to the [APPMANIFEST] specification.
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.
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].
When processing a MiniApp manifest, the process the lang
member algorithm is used to process the lang
member, according to the [APPMANIFEST] specification.
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.
When processing a MiniApp manifest, the process a text member algorithm is used to process the name
member, according to the [APPMANIFEST] specification.
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
When processing a MiniApp manifest, the process a text member algorithm is used to process the short_name
member, according to the [APPMANIFEST] specification.
The following member is defined in the Web App Manifest - Application Information specification [MANIFEST-APP-INFO].
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:
The following members are defined under the scope of the MiniApp manifest, addressing specific aspects of MiniApp.
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 value of
is RECOMMENDED to be a string defined by the following rule:
app_id
appIdRule = name *("." name)
name = ALPHA [*( ALPHA / DIGIT / "-" ) ( ALPHA / DIGIT)]
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:
The optional MiniApp manifest's color_scheme
member is a string that indicates the preferred color scheme of a MiniApp (i.e., "
", "auto
, or "light
"), overriding other configuration members of the window resource object, including dark
, background_color
, background_text_style
, and navigation_bar_text_style
.
navigation_bar_title_text
This member MUST contain one of the following color scheme values:
auto
"light
"dark
"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:
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).
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:
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
list defines the homepage or entry point of a MiniApp.
pages
To process the pages
member, given ordered map json and ordered map manifest:
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
, and target_code
.
release_type
To process the platform_version
member, given ordered map json and ordered map manifest:
min_code
member passing json["platform_version"] and platform_version.target_code
member passing json["platform_version"] and platform_version.release_type
member passing json["platform_version"] and platform_version.
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:
name
member passing item and permission.reason
member passing item and permission.
User agents will ask for the user's consent to protect their privacy during access to these specific features. This information in the
member may be used by app stores or hosting platforms to filter MiniApps according to the user's preferences, privacy policy, or device capabilities.
req_permissions
The MiniApp manifest's version
member contains a MiniApp version resource ordered map to represent the
and code
.
name
To process the version
member, given ordered map json and ordered map manifest:
code
member passing json["version"] and version.name
member passing json["version"] and version.
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:
name
member passing item and widget.path
member passing item and widget.min_code
member passing item, manifest, and widget.
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
object members inherit the text direction and language configuration from the window
and dir
members at the root of the MiniApp manifest.
lang
To process the window
member, given ordered map json and ordered map manifest:
auto_design_width
member passing json["window"] and window.background_text_style
member passing json["window"] and window.design_width
member passing json["window"] and window
enable_pull_down_refresh
member passing json["window"] and window.fullscreen
member passing json["window"] and window.navigation_bar_text_style
member passing json["window"] and window.navigation_bar_title_text
member passing json["window"] and window.navigation_style
member passing json["window"] and window.on_reach_bottom_distance
member passing json["window"] and window.orientation
member passing json["window"] and window.auto_design_width
member passing json["window"] and window.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:
TypeError
.TypeError
.TypeError
.TypeError
.app_id
member passing json and manifest.TypeError
.color_scheme
member passing json and manifest.description
member passing json and manifest.device_type
member passing json and manifest.pages
member passing json and manifest.TypeError
.platform_version
member passing json and manifest.TypeError
.req_permissions
member passing json and manifest.version
member passing json and manifest.TypeError
.widgets
member passing json and manifest.window
member passing json and manifest.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.
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:
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.
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:
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:
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.
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:
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:
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.
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:
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.
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:
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.
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:
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
list.
pages
To process the widget's path
member, given ordered map json and ordered map widget:
The optional MiniApp widget resource's min_code
member is a number that indicates the minimum platform version supported for a MiniApp widget.
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
explicitly, the user agent will consider the same requirement as the specified in the min_code
member in the min_code
object.
platform_version
To process the widget's min_code
member, given ordered map json, ordered map widget and ordered map manifest:
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.
The auto_design_width
member is a boolean that indicates whether the
of the page is auto-calculated by the user agent. When design_width
is auto_design_width
true
, the value of
is ignored. In this case, the system's baseline width is automatically determined according to the pixel density of the screen.
design_width
Value by default: false
.
To process the window's auto_design_width
member, given ordered map json and ordered map window:
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"
.
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.
The background_text_style
member is a string that specifies the background text style, indicating a light or dark color theme (i.e., "
" or "light
").
dark
This member supports the values of prefers-color-scheme and MUST contain one of the following background text style values:
light
"dark
" (default)
To process the window's background_text_style
member, given ordered map json and ordered map window:
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:
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:
The fullscreen
member is a boolean that indicates if the MiniApp is shown in full-screen display mode.
When this member takes the true
value, it is equivalent to the
value on the application manifest's fullscreen
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:
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:
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].
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:
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 (
) and display direction (lang
) defined at manifest's root.
dir
The following members are localizable members:
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.
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
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., icons
's icon
label
,
and name
) to enhance accessibility (i.e., icons in the home screen of the device, listing in app directories, and app configuration).
short_name
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
, and navigation_bar_text_style
) and other configuration settings like navigation_style
, orientation
, fullscreen
, and enable_pull_down_refresh
.
on_reach_bottom_distance
The manifest's
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 window
or fullscreen
. User agents must offer intuitive mechanisms to close the apps, reverting the changes that affected the native UI.
orientation
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.
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
, and pages
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.
widgets
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
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.
pages
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.
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
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 (req_permissions
member), informing the user about the potential consequences and granting (or keeping blocked) access to these resources. Developers SHOULD use the name
member to state the clear and easy-to-understand rationale for requesting these advanced resources.
reason
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
). This transparent information allows end-users to make a conscious decision before installing it. Based on this metadata, user agents MAY use digital signature methods within the package, as defined in MiniApp Packaging, to verify the app's integrity and maximize users' trust.
description
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.
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.
Developers interested in validating the MiniApp manifest document can use the JSON Schema defined at https://w3c.github.io/miniapp-manifest/manifest_schema.json.
This section is non-normative.
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.
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.
{
...
"wechat_new_feature": "foo",
"ali_new_url_system": "http://example.org",
"coolminiapp_menu_color": "#FA0000"
...
}
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: