Intent to Experiment: getInstalledRelatedApps()

[Peter Beverloo]

Contact emails

pe...@chromium.org, mgi...@chromium.org

Spec

https://github.com/WICG/get-installed-related-apps/blob/master/EXPLAINER.md

Summary

Allow sites to determine whether the user has installed their corresponding app, where the candidates to be checked are drawn from the "related_applications" key in the manifest.

We ran an Origin Trial for this feature in Chrome 59–61, which was later extended to Chrome 63. Matt has sent two updates following those trials:

https://groups.google.com/a/chromium.org/forum/#!topic/Blink-dev/0R7zbrVdhds

https://groups.google.com/a/chromium.org/forum/#!topic/Blink-dev/vrB0sJ0tQaI

It's been ten Chrome releases since the experiment ended, the mobile PWA field has continued to develop and we've continued to receive requests for getInstalledRelatedApps().

As such, we'd like to repeat the experiment to identify whether it's time to drive this feature forward. We've also published an article on developers.google.com to refresh interest:

https://developers.google.com/web/updates/2018/12/get-installed-related-apps

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/0xXsJYdkaWg/2NwHKmZBEAAJ

Goals for experimentation

Is there sufficient interest in access to this information from app developers to drive this feature towards standardization and shipping?

Experimental timeline

M73 - M76

Any risks from changing the API mid-experiment?

None. We are considering adding the ability to access the installed app's version to the result dictionary, but this will not create backward compatibility concerns.

Any risks when the experiment finishes?

None.

Ongoing technical constraints

Relies on specific features of Android, so is only available on that platform at the moment.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

No. This feature is specific to Android.

OWP launch tracking bug

https://crbug.com/587623

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5695378309513216

[Rick Byers]

It sounds like last time a key goal was to determine if the feature was sufficient to address the notification duplication issue, and the result was that it wasn't - service worker support was needed. Is addressing that issue still a goal? Have any changes/improvements to the design been made since last time?

Do you already have one or more customers who have expressed interest in evaluating this in the wild? It looks like we only got feedback on the trial from a single developer last time (though 66 origins had signed up). Are there reasons to believe there is more interest now?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2Btae9-ujL83u_-WYVt2QCFtwL-KGRUgJCbrh-ng2%2BQ58Xy2Mg%40mail.gmail.com.

[Peter Beverloo]

Partly - while the feature could be used towards deduplicating notifications, doing so comprehensively is a more complicated problem in which a developer also has to consider which account is logged in, per-app settings and so on. In practice we find that developers have found reasonable workarounds.

The new use case we've identified focuses on companion apps: there are cases where part of an application can be moved to the web, but part relies on close integration with the operating system. If a related app is installed, the developer might want to show UI to cross experiences. This is also why we're considering exposing the application version.

There is a large customer lined to use this feature, with whom we'll work closely to gather additional feedback. However, I don't expect the use-case to be unique, so am hoping for more information than the first time around.

Thanks,

Peter

[Rick Byers]

Makes sense, thanks for the additional context. 

LGTM