This is the first in a two-part series about the future of links. In this post, we will recap the history of links on the web and how things became so broken on mobile. Read part 2 here, where we cover the solution, and what we have learned at Branch as we built it.
Links are awesome. They’re the foundation of the web as we know it, and since this is the 21st century, we’ve all been surrounded by links for most of our lives. Pretty much everyone intuitively understands how to use one, but do you ever stop to think about how a link actually functions? Probably not, because the concept is so darn simple: when you click on a link, you are transported somewhere you wanted to go.
With such an obvious process, you could be forgiven for missing just how fragile this system really is.
Links on the Web vs. Links on Mobile
See, in the early days of the web, when each browser implemented things differently and “the internet” was something most people experienced as “that place outside of AOL,” there was a real risk that links could have ended up not “just working.” It was the widespread adoption of open standards that gave us the web as we know it today, and made search engines like Google (essentially just massive, ranked databases of trillions of links) possible. However, even this wasn’t without controversy.
We now take it for granted that Google search results consist of links that point directly to content, but many early webmasters were less than thrilled at the thought of users being “deep linked” into the middle of their sites. The proposed alternative was for every website to be a walled garden, accessible only through its own homepage and with internal content unreachable by any other approach. Fortunately for us, this future never materialized. The web has remained open and deep linking (whether via search engine or otherwise) is something we now use every day.
But does this alternative version of the early web sound somewhat familiar? It should, because this is the current reality for mobile apps. Native code has many advantages over web experiences, but content accessibility and discoverability are certainly not among them. So, now we have come full-circle back to the early days of the web, except that this time the walled gardens are a very real technical limitation rather than just a theoretical possibility.
Solving the Walled Garden Problem on Mobile by Rethinking Links
Can content be accessible and discoverable, regardless of platform or device type? The web and its well-defined link standards are not going away anytime soon, but the equivalent mechanisms for iOS and Android apps are still remarkably immature, despite anything Apple and Google may claim to the contrary. Right now, the behavior of a link often differs depending on things as innocuous as the version of the app in which it was viewed prior to being clicked.
To make matters worse, the digital landscape is now changing so rapidly that it is no longer safe to assume anything about how a given user will reach you — yesterday it was your desktop website, today it is your mobile website, tomorrow it could be in your native app, but next week it may be a completely new channel that hasn’t even been invented yet.
The recent trend in multi-platform linking (including iOS Universal Links, Android App Links, and Facebook App Links) has been distorting web links to also accommodate apps. With this approach, a regular web link points to multiple destinations simultaneously and the local client is responsible for determining which one to load. It’s fundamentally confusing, a hack on the existing system, and it breaks as soon as content exists on one platform but not another. Whether we like it or not, native apps are part of the future, and the links of the future cannot continue to be constrained by the limitations of workarounds like these. This is not good enough.
Instead, we need to take a fresh look at how we handle linking on the internet. A new approach to linking infrastructure is needed, adopting the best of what has worked in the past, but designed from the start to accommodate both websites and mobile apps, and flexible enough to adapt as future technologies come on the scene. “Deep linking” will be part of it, but what we need now goes far beyond that.
What we need now is a remote link service. An API for link routing. A dedicated link redirection server in the cloud. Hosted deep links. Whatever name you prefer, the reason for it is the same: as the mobile ecosystem becomes more fragmented, link routing is becoming too complex to handle locally on the user’s device. We are going to need something more powerful.
