[Web Install] Post-install updates

[dead-claudia]

After installing, a user might wish to update an application without immediately using it. UAs could also provide a centralized UI for checking and performing updates, like they already do for extensions.

A mobile user on the go will usually want to update while on Wi-Fi, but they might primarily use the app while on cellular, for instance.

This could be solved by just allowing UAs to manually fetch and update service workers without a window for installed web apps, to let them self-update.

[diekus]

@dead-claudia If I understand correctly, wouldn't periodic background sync already solve this?

[dead-claudia]

@dead-claudia If I understand correctly, wouldn't periodic background sync already solve this?

Not in its current state, because users typically want more control over update timings than web devs typically offer. Some examples:

1. The app developer may forget to check navigator.connection.type before updating, resulting in unwanted data usage or charges.
2. The user is on a metered Wi-Fi hotspot and the app developer always updates blindly while connected to Wi-Fi, also resulting in unwanted data usage or charges.
3. The app developer might just blindly prevent updates on cellular when, in reality, the user actually wants automatic updates on cellular. I already experience this issue with offline map updates with Here's WeGo app on iOS, so this isn't theoretical.
4. Users often want to intentionally delay an app update because of reported issues. App developers almost never grant this functionality natively.

1, 3, and 4 obviously could be fixed by the app itself. But as noted, the needs are typically caused by app devs failing to implement features in the first place. It's also uniquely useful to have a browser-global control for that, rather than having to specify it for every single site/app.

For 2, there are deep privacy concerns with even exposing a persistent hash for that, as it changes less than an IP address and thus could be used as a strong signal for identity. It's better and less risky to privacy for browsers to consume that and manage update scheduling on behalf of web pages.

A possible solution might be to allow user configuration of the minimum sync interval for individual tags (the spec does not make this clear), as well as a descriptive description property to help educate users on the purpose of the given sync tag.

Browsers in general IMHO could also offer an easier-to-access UI for managing installed web apps.

[dead-claudia]

There are also implications for the Web Install proposal, since they need to know to automatically install something. It's unclear whether service workers even run (though they probably should).