Making Durable, Reliable, and Dynamic Links On Mobile

Even now, eight years into the development of the mobile ecosystems, one of the most basic components of the modern web still doesn’t work: links.

Links are something every product and marketing team has taken for granted for years, since they worked so naturally and intuitively on the web. Everyone knows how it works: You click a link, the browser opens and loads the web page for that link, and tracking is incredibly easy because it’s baked naturally into the HTTP standard.

Those HTTP standards no longer apply in the mobile world. Cookies can only tell a fraction of the story causing fragmented and broken analytics. Links simply don’t work anymore.

Let’s take a look at a quick example so you understand what I mean. I’m a big fan of Mixcloud, where I can listen to mixes on the go. I have the app installed and am registered as a paying subscriber for the service.

One day, I received an email that one of my favorite artists had just uploaded a new mix. I scroll down in the email and press the ‘Listen Later’ button, launching a web page asking me to sign in. Why didn’t it just open up the app and add it to my queue? I close the mobile web and never end up engaging with the app.

We see these missed opportunities every day on mobile.

Why Mobile Links Break

There are many factors contributing to the downfall of links as we know them, but it all started when mobile consumers began to prefer the look and feel of a native app to mobile web. This effectively fragmented product and engineering teams, ultimately diminishing the overall user experience.

Mobile web could never offer the same experience that desktop web could because of two important factors:

1. Mobile websites are incredibly slow and clunky. It takes over a hundred milliseconds for a tap to be registered within a browser compared to a few milliseconds within the app.
2. Browsers are incredibly fragmented. On my iPhone alone, I have six different browsers with unique cookie space: Safari, Gmail, Facebook, Twitter, Pinterest, and Reddit. This results in cookies and session tracking becoming useless. You might decide to log in within the Gmail browser, then minutes later return in Safari to find that you’re logged out.

Regardless of the cause, mobile web is losing the battle and it doesn’t seem to be getting any better. A recent study by Flurry showed that on average, users only spend 20 minutes on mobile web compared with 3.7 hours in native apps.

What does this mean for links? Well it comes down to the concept of mobile deep linking. The expected and ideal behavior for a link is that it will open up the native app if it’s installed and show the page associated with the link (bottom). If the native app is not installed, the expected behavior is for the link to open up the browser and load the mobile web page (top).

Looks simple right? Unfortunately, it’s one of the most complicated and convoluted engineering challenges in mobile today.

Building Dynamic Links

We started Branch while we were working on our own app, Kindred Photo Books. All we wanted to do was link to special offers within the app, but we were always finding edge cases that broke our links. One day it was a legacy Android operating system version, the next it was a new update on Facebook iOS. Maybe we were just obsessive about covering every edge case, but we took every one of those cases seriously.

From these issues, one question arose: why hadn’t anyone solved mobile linking? That’s when we built Branch, and when other apps in our incubator batch starting asking if they could use our links, we knew we were on to something. We sold off our app and jumped head first into creating dynamic links for mobile.

Mobile linking is always evolving. Changes such as Apple’s Universal Links in iOS 9 and Google’s App Links in 6.0 have introduced a whole new set of complexities and edge cases that didn’t exist before, and we expect similar changes in the future.

We keep a team of people managing these edge cases, continually updating our core service to adopt new standards and technology. The apps that claim they’re going to build deep linking “in-house” tend to come back a year later with an unfinished solution, wishing they hadn’t wasted all that time. However, if you’re looking to try to build deep links yourself, we wanted to contribute a few learnings and share some key considerations.

iOS Universal Links and Android App Links

Both of these new link redirection techniques were introduced in iOS 9 and Android 6.0 to help companies open up an app when it was installed. They are extremely powerful and deliver the most optimum user experience, when they actually work.

For example, Universal Links only work when used in Apple-developed apps and a few messaging apps like Slack. They don’t work from most third-party apps. In Android 6.0, App Links have limited functionality in the Chrome Browser. While these Universal and App Links are the best solution when they actually work, it’s pretty clear they are not complete solutions.

Third-Party Apps With Webviews

Every large third-party app like Facebook or Twitter implements a webview inside their native app to handle all web page loading. This means that when you click a link on Facebook it opens a browser inside Facebook. This is done to keep their users within the app, and prevent them from going to another site.

Webviews force the third-party apps to implement deep linking and redirection. This means that every third-party app implements it however they prefer, leading to fragmentation and complexity. In fact, Facebook on iOS has actually broken all external app routing while Twitter and Pinterest still support different mechanisms.

Browser Type and Version

Browser fragmentation comes into play more frequently on Android but remains on iOS as well. Similar to how all third-party apps implement mobile linking differently, all browsers implement redirect differently. For instance, Chrome on iOS handles redirection to the app differently than Safari, and supports more techniques. But Chrome on Android handles redirection differently than the default browser or Firefox. And by the way, Chrome on Android handles redirection differently than Chrome on iOS.

Remember to install all popular browsers on a variety of phones and test your links or you’re bound to send users suboptimal places, or worse, to an error screen.

iOS and Android Operating System Versions

Finally, there are significant differences between operating system versions. This is not as big of a problem on iOS as it is on Android, but it must be taken into consideration. iOS 8 must be treated differently from iOS 9 just as Android 4 must be treated differently than Android 5 or Android 6.

Combine this with the browser types of webviews above, and the problem compounds on itself. For example, Facebook has different behaviors in Android 4 than it does on Android 5.

Yikes.

Dynamic Links for Every Edge Case

Above are some of the major edge cases which must be considered during the development of your mobile links. Make sure your linking team is adequately prepared with all of the devices and the range of variables listed above. Then, make sure to test your links when the app is installed AND uninstalled. Our current test matrix spans about 500 edge cases, and we run through it every few weeks to ensure that no recent updates haven’t resulted in broken links.

All in all, mobile linking is a tiring and time consuming endeavor. It’s an ever-changing space, that requires the attention of all mobile developers and marketers. However, if you make the investment, your users will thank you.

Read more: The Pros and Cons of iOS9