Won't related_application be needed at page load?

[marcoscaceres]

@mounirlamouri, won't you want this information at the head of the document so you can tell the user straight away that they can open/install the native app equiv.?

For example, the web page might be really slow to load, or the manifest might be slow to load... if this stuff was in the head, I could jump to the native app even before the web app loads. I've done this in iOS through Safari many times... it's nice not having to wait for the web page to load to access it's native app equiv.

[benfrancis]

@mounirlamouri Correct me if I'm wrong but I assumed the purpose of related_applications was to offer the installation of a non-web app at the point of installing a web app, not to handle navigations when just browsing to a URL which has a non-web equivalent. As non-web apps generally require installation before they can be used that seems to make more sense? As discussed elsewhere, once a non-web app is installed (e.g. on Android) it can handle navigations to deep links within the app's scope without waiting for a manifest to load. The scope gets registered at install time.

[marcoscaceres]

Correct me if I'm wrong but I assumed the purpose of related_applications was to offer the installation of a non-web app at the point of installing a web app, not to handle navigations when just browsing to a URL which has a non-web equivalent.

This would be sad, because it means you still need the proprietary meta tags: I think we would want to match what iOS does (which handles both the store link and allowing one to opening the app if it's already installed - even before the page has loaded!!!). This is exactly what is happening in the image below: the web page is less than half loaded and I can already jump to the app (I prefer that as a user, because in most cases the web app is crappy).

The same with the installation case. I can be prompted to jump to install the New York Times even before the front page has loaded. I might prefer that as a user ("oh, they got an app! sweet, will grab that instead!").

As discussed elsewhere, once a non-web app is installed (e.g. on Android) it can handle navigations to deep links within the app's scope without waiting for a manifest to load.

This is extremely fragile: the web application doesn't have a way of knowing if the user has the native application installed. This leads to the following situation where you can't deep link into anything with any certainty (invalid URL). So clicking "open in app":

Leads to:

Which devs are handling, onerror and routing apps to the appstore automatically (see AirBnB, which uses a routing service called "deeplink.yoz.io"). It's a hack, but it works (tm) and there are businesses built around this:

Unless you want one of these "onerror, redirect to app store" routers, you actually want the OS/UA to deal with that by allowing the user to open the native app or route the app to the app store automatically without showing the "invalid URL" error.

More sophisticated actions, like performing an action via a deep link in a native app, might require more infrastructure (as per whatever we discover as part of #363)

[marcoscaceres]

ok, so I was assuming people were using .onerror, but they seem to be using a timed redirect:

//try to go to the app, if it fails, jump to the appstore
setTimeout(function () { window.location = "https://itunes.apple.com/appdir"; }, 25);
window.location = "appname://";

See:

• How to check if an app is installed from a web-page on an iPhone?
• How to detect if a URL will open on phone?

[benfrancis]

And this is why I don't think a standard for web applications should try to fulfil the requirements of non-web applications. http://twitter.com is the web, twitter://timeline is not. Trying to graft one onto the other is just a hack. If operating system developers want to re-invent the web, that's their problem. A web standard should not be encouraging this kind of fragmentation.

If Apple would like to propose new features for the web, then I encourage them to participate in this discussion themselves.

[kenchris]

@slightlyoff comments?

[slightlyoff]

I don't think this needs to happen synchronously in the page load process. Chrome is happy to fetch the manifest asynchronously and prompt the user whenever the data comes back. Since we also enforce an engagement check (i.e., you never, ever see the prompt the first time you visit), the async nature isn't a problem for us. Suggest that other vendors consider doing the same, if only to avoid browser UI being used in a spammy way.

Also, agree with @benfrancis here: we shouldn't be inventing a solution for native app discovery with this spec. Perhaps some other mechanism for it will emerge, but it's up to the vendors to propose that, and related_applications isn't pitched to do that job.

[marcoscaceres]

Mozilla is not intending to support related_applications in the near future, so I'm happy to leave this for other implementers to propose something else if they need something on first load.