In last week’s post, we explained the problem of linking to apps. LinkedIn sends you an email with a link in it, you open the email on your smartphone and click the link, and you simply get taken to the LinkedIn mobile website.
The LinkedIn app, which you’ve taken the time to install on your phone and enter your login credentials into, is tragically and ironically never “linked in” to this process.
- Part 1: The problem
- Part 2: The solution
This post is about the solution for linking to apps, and how Quixey’s AppURL lets apps expose their functionality with all the same convenience we’ve come to expect from websites.
Try clicking this link:
If you’re reading this on a mobile device and you have the LinkedIn native app installed, the link above will launch it.
But if you don’t have the LinkedIn native app installed, or you’re not reading this on a mobile device, you’ll just see an ugly error from your web browser.
So what’s up with this weird URL,
A URL with anything other than “
http” (or one of these) before the “
://” part is called a “custom scheme URL”. When you install the LinkedIn app, it registers the fact that it can open
linkedin:// URLs on your device.
Custom schemes can actually do more than launch the LinkedIn app, they can launch the LinkedIn app into specific states. If you have the LinkedIn app installed on the device you’re using to read this, you can launch the LinkedIn app into a state of displaying info about Quixey’s Product Data Analyst, Victor Tran, by clicking this link:
This kind of linking into states within an app is analogous to deep linking into pages of a website.
http links, custom scheme URL links have a big advantage: they can launch apps. But they also have a big disadvantage: they don’t always work.
LinkedIn’s developers decided that the disadvantage of
linkedin:// links outweighs the advantage, and chose to use
http://links instead. Other developers feel the same way, which is why we have a problem linking to apps today.
Adaptively redirecting http URLs
We want a solution that has the app-launching power of custom schemes, but works everywhere like
http. We can do this by adaptively redirecting
To understand what that means, first notice that Victor’s LinkedIn profile has two URLs whose target platform (web vs. native app) is different, but whose functionality is the same:
The first URL works on every device with a web browser. To adaptively redirect it, all we have to do is make a special subset of web-enabled devices – the ones with LinkedIn’s native app installed – redirect the first URL to the second URL.
There’s another way to redirect
http URLs called appurl.org/go. Instead of putting the
http-to-custom-scheme redirection logic inside the destination web page, the redirection logic lives in an interstitial page whose URL starts with
The AppURL Paradigm
In the last section, we described two mechanisms for linking to apps by adaptively redirecting
appurl.org/go. But this one particular approach, adaptively redirecting
http URLs, isn’t the only way to robustly link to apps.
In fact, we see it is a short-term stopgap measure. Longer-term, we think the solution for linking to apps isn’t a technological mechanism for redirecting
http URLs, but rather a shift in the semantics of what an
http URL is.
On LinkedIn, Victor Tran’s profile is a single unit of functionality. Why does it need two completely different URLs?
We think Victor’s LinkedIn profile only needs one URL: the
http one. Not only is the
http URL universally compatible with all web-enabled devices, it’s also a more established scheme for identifying functionality on the web. And it’s registered globally and uniformly through ICANN - not on a per-device, per-app, platform-specific, device-specific basis.
In other words, we think custom URL schemes are a platform design mistake. In the world of shrink-wrapped software, which predates the internet age, applications like Microsoft Word are separate from websites. But in the world of mobile apps, well into the internet age, it doesn’t make sense to have separate launching mechanisms for websites and apps. The
http URL is fully capable of linking to apps.
The AppURL paradigm is that every piece of functionality inside every app is simply given its own
http URL, just like we’ve already come to expect from functionality on the web. More simply, the AppURL paradigm makes apps part of the web.
In part 1, we pointed out that a software state acts like a type of resource on the modern web, and the R in URL (“Resource”) has a broader definition today than in 1993. The AppURL paradigm gives the L in URL (“Locator”) a broader definition too, allowing functionality within installed native apps to be launched at the click of an
http link. AppURL broadens the semantics of the
http namespace beyond the semantics of HTTP.
At Quixey, we see apps as a natural addition to the HTTP web. We hope this sequence of posts has convinced you that the current state of linking to apps is a problem, and that the AppURL paradigm is an elegant solution.
For more information about AppURL, check out AppURL.org.