Deep Links, Universal Links, URI/URL Schemes, and App Links have all changed the world of linking to content inside mobile apps considerably over the last few years. This has left many app developers confused about which technology to implement and what the industry best practice is for each.
Additionally, the mobile deep linking landscape is still a rapidly evolving space. What worked a year ago is not necessarily the best approach today, if it is still possible at all. With years of outdated articles and misguided information, it is time to clear up misconceptions and provide a fresh take on the world of mobile deep linking.
What is Deep Linking?
First, some core terminology: “deep linking” is simply a concept. We use deep links every day — in fact, you probably clicked one to get to this blog post. The term just means “any link that goes straight to a piece of content.” When you click a URL like https://example.com/my-awesome-content-page, you don’t expect to be brought to https://example.com/ and be forced to navigate through the website to find the my-awesome-content-page again. Put another way, most links on the web are actually “deep web links,” but we don’t call them that. To us, they’re just “links.”
Deep linking in mobile apps is much more complicated, but mobile deep links are the still the best way to give app users a smooth content experience. Universal Links, URI schemes, and App Links are the various technology standards that make mobile deep links work, allowing you to bring a user directly to content inside an app. If you want to share a page inside of a mobile app with a friend, a deep link will bring your friend to the right page. Without a deep link, your friend would struggle to find the correct page on their own, and will often find themselves in the app store (even though the app is installed) or on the mobile web.
The process of implementing mobile deep links has evolved over the years, and Android and iOS have both offered their own solutions. This has caused confusion among the app development community, forcing even experienced engineers to update their links in spur-of-the-moment crisis situations, and confusing new engineers about the best path for implementing deep links in their app.
Here is a detailed breakdown of the various mobile deep link standards currently in use:
Note: iOS and Android together control 99.3% of the mobile market. Because of this, Branch has very limited support for other platforms, and they are omitted here for simplicity.
Of course, none of these standards is supported on every platform or OS version:
Facebook deserves special recognition for inventing an open-source deep linking standard that actually showed promise, and then completely abandoning it:
Let’s investigate each of these standards in a bit more detail.
What are URI Schemes? Are they different from URLs?
If you want to start a riot in a room full of engineers, you could have a debate about tabs vs. spaces for code indentation. Or you could mix up the difference between “URI and URL.” Essays have been written about this, but for our purposes just remember that all URLs are also URIs. The important part is the piece at the beginning: the “scheme”. You’re already familiar with the https:// and https:// schemes. You may even have encountered ftp:// or feed://. All of these indicate the type of content being requested, and your mobile app can register its own custom URI scheme. For example, myapp://.
If you are researching deep links, you probably have come across significant content about URI schemes. Throughout much of the history of app development, URI schemes were the primary method of deep linking into apps on both iOS and Android.
The Limitations of URI Schemes
Unfortunately, there are significant drawbacks to custom URI schemes, most notably the inability to easily handle these two situations:
- When the app isn’t installed.
- When more than one app tries to claim
myapp://.
URI schemes have no built-in fallback option, meaning that if a user doesn’t have an app installed when clicking a link shared by a friend, they will simply see an error page. There is also no central registration system, meaning URI collisions can happen (Apple’s official stance is “there is currently no process…”). Many developers built workarounds for the first issue using complicated JavaScript redirects, but these tended to break with each new iOS release. There will likely never be a solution for the second issue.
Because of these limitations, both iOS and Android have developed second generation deep linking standards known as Universal Links and App Links, respectively. Apple has since blocked the JavaScript redirection approach to URI schemes, making Universal Links essential for iOS deep linking. App Links have far seen far lower adoption.
How Universal Links and App Links Differ
Unlike URI schemes, which are a content “type” unique to your app, Universal Links and App Links are just standard deep web links (https://example.com) that point to both a web page and a piece of content inside an app. When a Universal Link or App Link is opened, the device checks to see if any installed device is registered for that domain. If so, the app is launched immediately without ever loading the web page. If not, the web link (which can be a simple redirect to the App or Play Store) is loaded in the default web browser.
If you are at all involved in measurement and analytics, you might be noticing a problem here: “app is launched immediately” means the traditional tracking methods for both web and email marketing — all of which are based on redirection chains — no longer work. This can be a significant problem, and both the Universal Links and App Links standards currently lack any solution. Your only option is to retroactively measure clicks after the app is opens.
Universal Links are the current standard on iOS, but have drawbacks
Universal Links are not actually “universal.” On major platforms like Facebook and Twitter, Universal Links are not supported at all, and the friendly-looking button in the top right corner gives no hint that it is essentially a “nuclear option.” Making it incredibly easy for a visitor to disable Universal Links without realizing it. Once done, it is extremely unlikely that a typical user will know how to reverse the process, leading them to assume it is your app that broke.
To make things worse, the Universal Links rollout was severely botched, and testing them is challenging since Apple does not even provide a validator tool.
Are URL/URI Schemes Obsolete?
According to Apple, yes. Starting from iOS 9.2, Apple no longer officially supports URI schemes for deep linking, and developers were forced to implement Universal Links in order to get equivalent functionality on iOS.
In reality, not yet. Universal Links are great when they work, but there are still plenty of places where you need to use URI schemes as a back up and you are leaving a significant amount of traffic on the table if you rely on them exclusively. The Android ecosystem is far too fragmented to even consider abandoning URI schemes at any point in the near future.
Deferred Deep Links
There is one more important concept we haven’t discussed yet: deferred deep linking. Standard deep links — whether implemented through URI schemes, Universal Links, or App Links — only work if the app is already installed on the device. If not, they can – at best – send your users to the App or Play Store. But what if you want to send users to the right place inside the app, even if they have to install it first? Deferred deep links allow this to happen, by keeping context of the specific piece of content through the install process, taking the user to the correct place after install.
Other Deep Linking Standards
You may also run into two other, less common deep link standards: Chrome Intents and Facebook App Links.
Chrome Intents
The Chrome team has built their own, home-grown extension to custom URI schemes, with the intention of providing fallback behavior when the app is not installed. While an elegant solution to the underlying problem, Chrome Intents are supported only on the Android version of the Chrome browser and a handful of third-party apps. This means added complexity for every deep linking implementation, as you now need to support both the standard technologies and a Chrome-specific alternative.
Facebook App Links
Facebook created App Links in 2014 as an open standard to solve the limitations of URI scheme deep links. App Links have two main components:
- A set of meta tags to add to the web page destination of a standard https:// link. These tags specify the custom URI scheme location of corresponding content inside the native app, and the behavior that should occur if the app is not installed.
- A routing engine for use inside apps that support opening links. This engine checks the destination URL for App Links tags before opening it, and then launches the corresponding app or executes the specified fallback behavior.
https://applinks.org/documentation/
The App Links standard has a critical limitation: it requires work by both the origin and destination apps. While the meta tags component saw wide adoption, the only major implementations of the routing engine were in the core Facebook and Messenger apps. Facebook now prefers to keep users inside its platform, and has removed the App Links routing engine from everywhere except the main Android app. Since Facebook also blocks iOS Universal Links, this leaves no reliable way to open third-party apps from Facebook or Messenger on iOS. Branch has implemented a solution to help work around these limitations and use Universal Links to deep link off of Facebook.
Universal Links, URI Schemes and Deep Links in 2017
The mobile app deep linking landscape is still incredibly fragmented. We are still nowhere close to an industry-wide standard. However, this is no excuse for inflicting a poor user experience on your customers.
You need deep links, and you need all of the different standards to get them. Branch deferred deep links are powered by URI schemes, Universal Links, App Links, Chrome Intents, and Facebook App Links. We included all of them so that you don’t have to.
Interested in implementing deep links that handle all of these different standards and provide unified analytics and attribution data without any additional work on your part? Click here to request a Branch demo.