Intent to Implement and Experiment: AppInstalled API

[Daniel]

Contact emails

dhn...@chromium.org, owe...@chromium.org

Spec

https://github.com/DHNishi/IsNativeAppInstalled/blob/master/explainer.md

Summary

The AppInstalled API allows sites to determine whether their corresponding native applications or Progressive Web Apps are installed. For native applications, sites are only allowed to use this if they have an established association with the application and vice versa. We use the “related_applications” section of the app manifest, to determine which apps the site claims are associated.

Motivation

If a mobile site sends a push notification to a user who has the native app installed and has granted the notification permission to the site, the user is shown duplicated notifications, one from each version of the service. It is currently impossible to deduplicate these without hacks and heuristics. With an API like AppInstalled, sites can avoid this confusion.

Allowing sites to determine whether their native application is installed allows them to improve the UX of more app-like features. Other use cases involve avoiding upselling users to install the app when the app is already installed.

Goals for Experimentation

• Is this API surface convenient for developers?

• What sort of websites are interested in this API?

• Is this API sufficient for apps developers who need to selectively perform actions, such as determine which platform to send notifications to?

Experimental timeline

Enabled:

• April 8, 2016: Chrome 51 Branch to Dev.

• May 31st: Chrome 51 Stable*.

• July 1st: Chrome 53 Branch to Dev.

• 4 weeks of 50 stable channel feedback.

• July 26th: Chrome 52 Stable*.

• August 26th: Chrome 54 Branch to Dev.

• 10 weeks of 50 stable channel feedback.

• 4 weeks of 52 stable channel feedback.

• September 6th: Chrome 53 Stable*.

Disabled:

• October 18th, 2016: Chrome 54 Stable*. Initial experiment terminates.

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

The experiment will initially only support Android. This feature matters most for mobile use cases and a framework exists for verifying links between Android apps and websites.

Compatibility Risk

None of the other vendors have public signals for this new API. Due to launching under the Experimental Framework, risk to compatibility is minimal.

Ongoing technical constraints

There is some risk in that this feature requires a stable system for defining associations between origins and apps for each supported platform.

OWP launch tracking bug

crbug.com/587623

Link to entry on the feature dashboard

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

[Vincent Scheib]

Timeline:

Some version numbers corrected:

Enabled:

• April 8, 2016: Chrome 51 Branch to Dev.

• May 20th: Chrome 52 Branch to Dev.

• May 31st: Chrome 51 Stable*.

• July 1st: Chrome 53 Branch to Dev.

• 4 weeks since 51 Stable.

• July 26th: Chrome 52 Stable*.

• August 26th: Chrome 54 Branch to Dev.

• 12 weeks since 51 Stable.

• 4 weeks since 52 Stable.

• September 6th: Chrome 53 Stable*.

Disabled:

• October 18th, 2016: Chrome 54 Stable*. Initial experiment terminates.

• 20  weeks since 51 Stable.

• 12 weeks since 52 Stable.

• 6 weeks since 53 Stable.

[Dimitri Glazkov]

On Fri, Feb 26, 2016 at 12:07 PM, Daniel <dhn...@chromium.org> wrote:

That's not quite how it works. Just because we have the EF doesn't mean we don't need to follow the same steps as we usually do to achieve interop, however eventual. Please don't implement/EF stuff until you at least started down this path.

[Owen]

As an update, Dimitri and I have spoken - he and Alex Russell have set some time aside to discuss how much standards pre-work they believe would be good for features we're experimenting with via the Experimental Framework. We also agree that we'd like not to to block this intent on full resolution there.

Regarding steps to achieve interop:

- We've shared this proposal and chatted in real life with folk at Mozilla including bwalker and jconlin.

- Alex Russell has given an API review which resulted in Daniel modifying the surface in a way that the three of us were happy with, which is reflected in the proposal above.

Thanks

[Dimitri Glazkov]

I am okay with that.

:DG<

[Matt Giuca]

Hi all,

It's time to give an anniversary update on this feature.

The API (now known as navigator.getInstalledRelatedApps) has been implemented on Android and is now available on Dev and Canary behind the --enable-experimental-web-platform-features flag.

We are planning to roll out an Origin Trial for this feature in M59 (which allows sites to register to receive a token to use the API for a limited time). More details to come, including better documentation and sample apps.

Matt

[naveenar...@gmail.com]

Has this been implemented or is it still in the experimentation phase?

[Matt Giuca]

Hi,

FYI (to avoid confusion): "AppInstalled API" was renamed (a long time ago) to "getInstalledRelatedApps". In the mean time, we implemented a new, completely unrelated event called "appinstalled". This thread is about the getInstalledRelatedApps method, not the appinstalled event.

On Fri, 20 Apr 2018 at 07:41 <naveenar...@gmail.com> wrote:

Has this been implemented or is it still in the experimentation phase?

This ran an experiment for 5 milestones (summary here: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/vrB0sJ0tQaI)

At this time, the experiment has been concluded and we do not intend to release the API. A discussion for what may replace it is on GitHub here: https://github.com/w3c/manifest/issues/658

 

--
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/6dfb785b-513c-4017-85e4-501b5dc24725%40chromium.org.