Design Review #1076

#1076: TAG review for making app updates more predictable

Opened Apr 2, 2025

こんにちは TAG-さん!

I'm requesting an early TAG design review of predictable app updating.

The design proposes a way to have PWAs fully update their identities in a safe and resourceful manner, to further bridge the gap between PWAs and native apps. This is done by updating the manifest spec to use icon urls for making updates more deterministic by the developer, and for providing a consistent experience. The proposal attempts to do so in a way that uses less resources and prevents user confusion by showing the update UX less often.

Explainer¹: https://github.com/WICG/manifest-incubations/blob/gh-pages/predictable-app-updating.md
User research: N/A
Security and Privacy self-review²: https://github.com/WICG/manifest-incubations/blob/gh-pages/predictable-app-updating-security-privacy-questionnaire.md
GitHub repo: https://github.com/WICG/manifest-incubations
Primary contacts:
- Dibyajyoti Pal, Google
- Dan Murphy, Google
Organization/project driving the design: Google Chrome
This work is being funded by: Google
Incubation and standards groups that have discussed the design:
- TPAC
Standards group(s) that you expect to discuss and/or adopt this work when it's ready: WICG
Multi-stakeholder feedback³:
- Chromium comments:
  - Chromestatus entry: https://chromestatus.com/feature/5148463647686656
  - Blink I2P: https://groups.google.com/a/chromium.org/g/blink-dev/c/fWPN6TDuv-4
- Mozilla comments: N/A
- WebKit / Developer comments:
  - TPAC minutes 2023
  - TPAC minutes 2022
Major unresolved issues with or opposition to this design: N/A
[ X ] I have reviewed the TAG's Web Platform Design Principles

Discussions

Discussed Apr 1, 2025 (See Github)

Christian: need to discuss with Martin

Comment by @martinthomson Apr 29, 2025 (See Github)

@Dp-Goog Thank you for your proposal and contribution, the TAG has discussed this (with thanks to @christianliebel who drafted most of this comment).

We understand your proposal introduces an additional update mechanism for app shortcuts for Chromium-based browsers. Specifically, your proposal suggests adding an update_token member to trigger manifest updates only when its value changes. Without this member, updates would always occur at the next possible opportunity. This approach seems to address specific challenges, such as unnecessarily triggering icon updates due to CDN re-encodings or minor design alterations.

We have reservations about introducing an update_token member for this purpose. This mechanism appears unconventional within the web platform (which values would you expect there?), and there is a risk that developers may overlook the update_token field. Additionally, updating shortcuts seems to be handled differently by various engines: While Chromium-based browsers prompt users with a confirmation dialog for security-critical updates, WebKit appears not to update shortcuts once added to the home screen or dock.

We believe updating app shortcuts and icons after installation must be possible, but there should be a single approach to it. We recommend that you start a broader discussion within the WebApps working group to explore an approach that ideally works across various engines and platforms. The results of this discussion could enhance the Updating the manifest section of the Web App Manifest specification, which currently lacks a detailed description (see https://www.w3.org/TR/appmanifest/#updating).

As one possible solution to the issue with CDN re-encodings, we suggest treating icons as Cache-Control: immutable, which means that there is no guarantee that the icon would update unless the URL changes (that would be down to UA choices). This would achieve a similar outcome to your proposal without needing an update_token. The consequence being that authors relying on automatic icon updates would have to be informed about this change, though (as above) that's already uncertain.