Intent to Implement and Ship: Rich PWA installation dialogs

Skip to first unread message

Finnur Thorarinsson

Feb 25, 2021, 9:26:04 AM2/25/21
to blink-dev,

Intent to Implement and Ship: Rich PWA installation dialogs

Contact emails,,


Following this intent, we would like to start using the “description” and “screenshots” members of the Web App Manifest Application Information draft to provide a richer, more informative installation experience for users.

Because the effect of this will be visible to users, rather than developers, it’s important to note that the feature will be rolled out as a Finch experiment to validate that it has the ability to add value.


TAG review

These properties were included during the original Manifest TAG review: 


Most browsers have facilities to enable users to add a website to their homescreen. 

Several browsers provide the ability to install PWAs. Currently the context that’s available to convey is the website’s origin, as well as the name and icons made available through the Web App Manifest. This is different from other store mechanisms, on all platforms, that also share developer-provided information such as a description and screenshots.

Microsoft’s Aaron Gustafson (cc’d) has proposed a Web App Manifest Application Information draft, through which we can obtain that information.

Following this intent, Chrome for Android will start experimenting with a new, richer user interface that displays this information when the developer has provided it. We’ve carefully designed this interface to continue to highlight known information such as the origin, and are working with the permission and privacy teams to make sure we can evolve it responsibly going forward.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No. The manifest members are platform agnostic, but this implementation applies to Android only for now (Desktop work is planned).

Demo link

  1. Enable the “Mobile PWA Installation bottom sheet” flag on chrome://flags

  2. Visit

  3. Press the Install button and observe the new bottom sheet.


Interoperability and Compatibility

This is a new feature that requires developers to provide new fields in their manifest. There is no change in behaviour for websites that don’t, and we continue to enable installation for such websites as well.

There are various on-going discussions about what it means to install a PWA, particularly in regards to it being a security boundary. This particular intent has no impact on that decision, but composition of information in installation prompts may be revisited in the future.

Edge: Positive (they proposed the specification)

Firefox: No signal (issue).

Safari: Descriptions are implemented (thread, code), but not exposed in UI. No signals for screenshots (bug).

Web / Framework developers: Positive (tweet with 38 Retweets and 135 Likes, 42 stars on the implementation bug).


There is no change in behaviour for developers who do not adopt this feature. For those who do, there will be a slight delay in showing the install dialog while the screenshots are downloaded.


Description and screenshots are optional fields and there is no need to polyfill because PWA installations will continue to work as they do today if these fields are not supplied. Developers who do not adopt this feature will therefore see no change, but we will reach them through the usual social media channels, as well as through targeted partner outreach. 


DevTools debugging support is currently available to help web developers diagnose installability issues with screenshots. Those are available in the Manifest pane of the Application panel.

Tracking bug

Launch bug

Chrome Platform Status

Is this feature fully tested by web-platform-tests? Link to test suite results from

Not yet, there is an open issue for this: 

It’s worth noting that WPT in this instance may be able to validate existence and reflection of the properties, but will not be able to cover how a user agent uses the information. This has been added to Chromium as Android JUnit tests, but will continue to be platform specific.

Chris Harrelson

Mar 11, 2021, 2:46:02 PM3/11/21
to Finnur Thorarinsson, blink-dev,

Sorry for the slow reply.

I have two questions about this feature:

- Do you have information about how many existing PWAs might have this information exposed? Consider the case of a PWA that fills out these fields, but since they aren't being used or exposed prominently, they would be surprised by this change.

- What does it mean for Safari to parse but not use the fields? Is there something web-exposed about this behavior that can be detected?

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Finnur Thorarinsson

Mar 23, 2021, 8:53:50 AM3/23/21
to Chris Harrelson, blink-dev,

Hi Chris,

Thanks for the questions. I also apologize for my late reply -- it took a bit of time to gather and process the information requested and a couple of sick days didn’t help either.

1) Do you have information about how many existing PWAs might have this information exposed? 

We inspected the manifests of the most popular PWAs installed on Android, which together represent more than half of installs seen this year. Only about a third included the ‘description’ field but none of them included the ‘screenshots’ field. Since both fields are required for this feature, we could not find any PWA within that set that would trigger the showing of the new richer install UI.

It’s worth adding that, despite being previously unused, all the ‘description’ fields we encountered had sensible values, so it looks like this was very much anticipated by developers.

2) Consider the case of a PWA that fills out these fields, but since they aren't being used or exposed prominently, they would be surprised by this change.

There is little incentive for developers to have provided this data if they did not anticipate that it would get used, as we have never checked for it, let alone validated it. Even if the showing of this information in this particular user interface may come as a surprise, by nature both a site's ‘description’ and ‘screenshots’ are clearly intended to represent their property.

Furthermore, it is hard to determine whether people will be surprised by this change or delighted, because developer enthusiasm has already led to sites starting to fill this out in anticipation of launch. For example, see Discourse comment on the feature bug

3) What does it mean for Safari to parse but not use the fields? 

It means they’ve implemented the code to parse the manifest (including the ‘description’ field) but they are currently not exposing the data in their UI. We don’t know what their intentions are for using the information as they’ve not responded on this topic (to my knowledge).

4) Is there something web-exposed about this behavior that can be detected?


Best regards,


Chris Harrelson

Mar 23, 2021, 11:56:59 AM3/23/21
to Finnur Thorarinsson, blink-dev,
Thanks for the compatibility research!


Yoav Weiss

Mar 24, 2021, 1:53:32 AM3/24/21
to Chris Harrelson, Finnur Thorarinsson, blink-dev,

Daniel Bratell

Mar 24, 2021, 5:34:59 AM3/24/21
to Yoav Weiss, Chris Harrelson, Finnur Thorarinsson, blink-dev,
Reply all
Reply to author
0 new messages