Proposal: Get Installed Related Apps API

Get Installed Related Apps

The proposal in this Git repo presents an API to determine if native apps related to the current web app are installed.

From our explainer document:

As the capabilities of the web grow, the functionality of web apps begins to match that of corresponding native apps. The situation of users having a web app and the corresponding native app both installed on the same device will become more common, and the feature sets of these apps will converge.

It is important to allow apps to detect this situation to allow them to disable functionality that should be provided by the other app.

The explainer document has more details.

Context: I am the PM for push notifications on the Chrome team.

We have repeatedly heard requests from current and future potential push adopters for this feature. Specifically, many companies are very anxious about annoying users by accidentally sending them push notifications multiple times if they have enabled them from the web but also have the native app installed.

I believe this feature is generally useful, and will have extremely large value for push notifications adopters on the web.

This should already be a thing.

And yes, it’s very, VERY annoying to get the same notifications on at least 3 devices (usually more)

So, I’m in full support around the problem that this sets out to solve (and that we need to solve it)… though I’m still trying to digest the current proposal: at first glance, it worries me that an application is reaching into the OS to get information about installed apps.

Going to go read a bit more, as I’ve just had a super quick glance (so probably should not even be commenting, but YOLO ^_^)… but I would expect some kind of “request ownership” model (similar to intents today) and some kind of browser or OS provided UI: where the user is given the choice as to where push notifications should be routed (either the native app or the web app - but the user is given the ultimate control).

Maybe the API allows for this… will take a detail look now. Just my initial 2c.

The current proposal allows sites to determine whether the corresponding native app is installed.

That site can then choose to:

• Automatically disable notifications for one of the implementations
• Give the user choice between receiving notifications from each

This sounds like a pretty good solution to me, I can’t see any “platform solution” to allowing the user to choose between getting notifications from each hence supporting this proposal. This feels like a pretty good layering of APIs too - this way sites can check if their native app is installed, and if so simply not request push permission in the first place.

I think that this is a dangerous implement as specified. But the goal is laudable.

A lot of this comes down to how the relationship is discovered. For instance, an application on an arbitrary platform does not have an origin in the web sense, so it cannot possibly identify itself to the browser as being able to control that origin. Thus, from the perspective of a browser, this needs to be a thing involving mutual consent.

To add further complication, enumerating applications - or origins - without some sort of gatekeeper function is difficult from a privacy perspective. The explainer doesn’t really address this very well.

I use a couple of native applications that manage the relationship between native and web presence fairly elegantly. The application just opens a browser tab to a site that the application controls and then web login information (latent in cookies) is coupled to my application details. This might require authorization or login, but the basic premise is simple enough. You could even hide this until the first case where a browser is plausibly needed, like when the user clicks on a link.

The opposite might be more difficult, since we’re still very much in the throes of working out how a web application talks to a native application, and I’m not up on the latest there.

My point being that it’s not clear that there isn’t any need for a spec here. The explainer is a little worrying in its current form.

Thanks for the comments! I recently put this issue on the github repo which raises the same privacy concern and also larger questions of whether this is the right approach.

It would probably be best to discuss the API on the github, but since we’re here already…

Regarding the privacy issue, on Android it is possible to define a two way relationship between a native app and a web app. A given web app would only be able to query native apps defined in this way.

The link from the web app to the native app is made through the existing related_applications field in the manifest spec. Similarly native Android apps can define relationships to web apps via their manifest.

Do you think this is sufficient? Are the problems you’re seeing that the explanation isn’t detailed enough, is just Android, or that these mechanisms are insufficient?

Although it would be nifty to have this functionality, I’m not sure I understand the use cases or whether or not it is some serious need for it. I guess, like a few people already mentioned, this is helpful when notifications are sent from both website and native app, but the user does have the ability to silence notifications from either place if they get overwhelming. I actually prefer to have this control as a user and not allow the website author to do this for me.

Are there any other use cases where this API would be beneficial to warrant the work involved?

This particular case is, in my humble opinion, a totally solvable problem from the developer side. Since the client app should send the endpoint to the app server, that request can identify the client as the web or native client. The server can choose between replacing the current endpoint or instructing the client to prompt a dialog to the user and let they decide instead.

You cannot use the endpoint of a push subscription to identify a particular device, unless you also require the user to log in. That would be a significant security issue.

In essence, the problem of duplicated functionality is not unique to Web apps. Having both the stable and experimental version installed of any app can lead to the very same issues. Android Apps can solve this by using the Device ID. iOS apps can use a UUID that’s unique per app vendor.

The Web (fortunately) does not expose any sort of unique Id to users. Instead, Web apps tend to use a combination of the device, OS and screen size information to try to reach a similar result. That is not always sufficient, but more importantly, may lead to races when events happen, e.g. when receiving a notification.

By that time we’ve already lost, because the user is presented with the same information twice.

I believe this proposal has a lot of potential. It definitely addresses a real issue. We can give developers more certainty and enable them to build the UI for allowing users to make a decision. Requiring both sides to declare the relationship seems good, although we might want to think about limiting that to the origin as opposed to related_applications.

One case that advocates for Marcos’ thoughts is using different kinds of apps for different accounts. Some form of limited negotiation or acknowledgement could work there. While that’s not super common, it’d be good to at least keep the door open.

it is really useful, currently we are using TWA app and Webapp. In the case if user has installed TWA we dont want to show the banner ‘Add to home screen’ and it is very confusing if user install both TWA app and PWA on android. We are using trial and working perfect, waiting for public.