Deeplinking mobile browsers to native app - Issues with Chrome when app isn't installed

Question

I have a webpage, lets call it entry.html.

When a user enters this page, a javascript code (see below) is attempting to deep-link the user to the native iOS / Android app.

If the deep-link fails (probably if the app isn't installed on device), user should "fall back" to another page- lets call it fallback.html.

here is the javascript code that is running on entry.html:

$(function(){
    window.location = 'myapp://';
    setTimeout(function(){
        window.location = 'fallback.html';
    }, 500);
});

this is a standard deep-linking method that is recommended all over the network; try to deep-link, and if the timeout fires it means that deep-link didn't occur- so fallback.

this works fine, as long app is installed on device.

but if the app isn't installed, this is the behaviour when trying to deep-link:

Mobile Safari: I see an alert message saying "Safari cannot open this page..." for a moment, and then it falls-back properly to fallback.html- which is the expected behaviour.

Mobile Chrome is my problem.

when the app isn't installed, browser is actually redirected to the myapp:// url, which is of course, invalid- so i get a "not found" page, and fall-back doesn't occur.

Finally- my question is:

How can I fix my code so FALL-BACK WILL OCCUR on mobile Chrome as well? just like mobile Safari?

note: i see that LinkedIn mobile website does this properly, with Safari & Chrome, with or without the app installed, but i couldn't trace the code responsible for it :(

note2: i tried appending an iframe instead of window.location = url, this works only on Safari, mobile Chrome doesn't deep-link when appending an iFrame even if app is installed.

Thanks all!

---

UPDATE:

i found a decent solution, and answered my own question. see accepted answer for my solution.

Answer 1

for whoever is interested, i managed to find a decent solution to solve these issues with deeplinking Chrome on Android.

i abandoned the myapp:// approach, i left it functioning only in cases of an iOS device.

for Android devices, i'm now using intents which are conceptually different than the myapp:// protocol.

I'm mainly a web developer, not an Android developer, so it took me some time to understand the concept, but it's quite simple. i'll try to explain and demonstrate MY solution here (note that there are other approaches that could be implemented with intents, but this one worked for me perfectly).

here is the relevant part in the Android app manifest, registering the intent rules (note the android:scheme="http" - we'll talk about it shortly):

<receiver android:name=".DeepLinkReceiver">
    <intent-filter >
        <data android:scheme="http" android:host="www.myapp.com" />
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.BROWSABLE"/>
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</receiver>

now, after this is declared in the app manifest, i'm sending myself an email with "http://www.myapp.com" in the message.

when link is tapped with the Android device, a "chooser" dialog comes up, asking with which application i want to open the following? [chrome, myapp]

the reason this dialog came up upon tapping on a "regular" url, is because we registered the intent with the http scheme.

with this approach, the deeplink isn't even handled in the webpage, it's handled by the device itself, when tapping a matching link to an existing intent rule defined in the Android app manifest.

and yes, as i said, this approach is different by concept than the iOS approach, which invokes the deeplink from within the webpage, but it solves the problem, and it does the magic.

Note: when app isn't installed, no chooser dialog will come up, you'll just get navigated to the actual web page with the given address (unless you have more than 1 browser, so you'll need to choose one... but lets not be petty).

i really hope that this could help someone who's facing the same thing.. wish i had such an explanation ;-)

cheers.