|
|
|
|
A web app manifest is a JSON file that tells the browser how your Progressive Web App (PWA) should behave when installed on the user's desktop or mobile device. The manifest file can have any name, but it's commonly named manifest.json and served from the root (your website's top-level directory). The specification suggests the extension should be .webmanifest, but you might want to use JSON files to make your manifests clearer to read. When a user installs your PWA, you can define a set of icons for the browser to use on the home screen, app launcher, task switcher, splash screen, and in other places. The icons property is an array of image objects. Each object must include the src, a sizes property, and the type of image. To use maskable icons, sometimes referred to as adaptive icons on Android, add "purpose": "any maskable" to the icon property. For Chromium, you must provide at least a 192x192 pixel icon and a 512x512 pixel icon.
If only those two icon sizes are provided, Chrome automatically scales the icons to fit the device. The id property lets you explicitly define the identifier used for your application. For more information, see Uniquely identifying PWAs with the web app manifest ID property. It tells the browser where your app should start when it launches, and prevents the app from starting on whatever page the user was on when they added your app to their home screen. Think about what the user will want to do immediately after they open your app, and place them there. You can customize what browser UI is shown when your app is launched. For example, you can hide the address bar and browser user interface elements. Games can even be made to launch in full screen. To choose how your web app is displayed, set a display mode in its manifest as explained earlier.
Browsers aren't required to support all display modes, but they are required to support the spec-defined fallback chain ("fullscreen" ? "standalone" ? "minimal-ui" ? "browser"). If they don't support a given mode, they fall back to the next display mode in the chain. In rare cases, these fallbacks can cause problems. For example, a developer can't request "minimal-ui" without being forced back into the "browser" display mode when "minimal-ui" is not supported. The current behavior also makes it impossible to introduce new display modes in a backwards-compatible way, because they don't have a place in the fallback chain. Its value is a sequence of strings that are considered in the listed order, and the first supported display mode is applied. If none are supported, the browser falls back to evaluating the display field. The details of "window-control-overlay" are out of scope for this page. When loading this app, the browser tries to use "window-control-overlay" first. If that's unavailable, it falls back to "minimal-ui", and then to "standalone" from the display property.
If none of these are available, the browser then returns to the standard fallback chain. The scope of your app is the set of URLs that the browser considers part of your app. URL structure that includes all entry and exit points to the app, and the browser uses it to determine when the user has left the app. If you don't include a scope in your manifest, then the default implied scope is the start URL, but with its filename, query, and fragment removed. The scope attribute can be a relative path (../), or any higher level path (/) that would allow for an increase in coverage of navigations in your web app. For example, you can define one color for light mode and another one for dark mode in this way. However, you can't define these preferences in your manifest. The shortcuts property is an array of app shortcut objects that provide quick access to key tasks within your app.
|
|
