Note: This method no longer works

I haven’t tried it myself, but I’m told this method no longer works. Unfortunately, I no longer work in this area and don’t have a workaround. Perhaps the information below will inspire a different solution.

Hating on Gmail

Recently I needed to e-mail a message that included a link to open an app on iOS devices. iOS supports this so long as the app is installed and has registered a custom URL scheme. Great, hyperlinking is a skill I have.

Normally, I would also worry about what happens when the link is clicked on non-iOS devices, but I believe the expected behavior for clicking “Open MyiPhoneApp” on a PC is… nothing. Which is what happens.

However, after a bit of testing it turns out that Gmail strips out these links entirely, both in the browser and in the iOS app. Not only does this mean Gmail app users can’t use my link, but viewing the email in the browser suggests that my Launch button isn’t even a link.

Link behavior

I had several very specific criteria that my link had to meet:

1. The app should open as quickly as possible
2. An Internet connection should not be required
3. There should be some reasonable behavior on non-iOS devices
4. The link should work even in the Gmail app

Abusing HTML links

The first three of these can be accomplished with a plain hyperlink using the custom URL scheme. Since that is my preference, let’s take advantage of loose HTML interpretation.

The basic idea is to have two separate links: one to link directly into the app, and a second to do some simple redirect magic we will see in the next section. The app link should be preferred, but if it is automatically removed, say by Gmail, then we can use the second link instead.

Carefully crafting a (non-HTML compliant) link as follows is the solution:

<a  href="my-app://deep-link"
    href="http://example.com/backup-link"
    href="my-app://deep-link"
>Link Text</a>

By bracketing the backup link with the desired link, browsers (at least those I’ve tested) will ignore the backup link, except when the desired links have already been stripped out by Gmail.

The backup link

Obviously, the backup link can be whatever you want. I chose a link that goes to a dynamically-generated page (that I host) with a simple piece of logic. If the user is on an iOS device (by user-agent), then return a 301 or 302 HTTP Redirect to my-app://deep-link. If not, then return a 301 or 302 HTTP Redirect to some sane location, such as the app’s website or App Store page.

The behavior of this link is slightly less desirable that the direct link. The backup link requires an Internet connection, and even when one is present the link first loads an intermediate page before the app which is both slower and presents another opportunity for failure. Even so, this is acceptable given that the direct link was removed on our behalf.

Less than perfect

The astute reader may notice that there are still several situations in which a user can click a link that has no apparent effect. I think that this is totally acceptable given the context in which the link is presented, but this method tries to ensure that the link is always clickable, even if the destination is unavailable.