Universal links on iOS vs. deep links (URL schemes)
As I'm reading, iOS 9 introduced Universal Links. In the "Support Universal Links" section in Apple's App Search Programming Guide, it says that this is not exactly like deep linking with URL schemes, but I'm not totally clear about this topic:
- What is actually the difference(s) between Universal Link and the URL Schemes? Is it that a Universal Link is only for hyperlinks in websites, and the Mail or Messages apps?
- Do Universal Links replace URL schemes?
- Are Universal Links a type of deep link?
Answer
TL,DR:
What is actually the difference(s) between Universal Link and the URL Schemes? Is it that a Universal Link is only for hyperlinks in websites, and the Mail or Messages apps?
A Universal Link is an Apple Specific, OS-based URL that ties a website URL to an app-specific URI Scheme & Route. It is not available in all apps - as the app has to support the behavior. There is a good list of where/how UL's currently work (here).
There are tons of problems with UL's as well which I outline at the very end. See long read below.
Do Universal Links replace URL schemes?
No. They are a forced replacement for URI Schemes and routes on iOS Safari. You must and should still support your app's URI scheme and routes since Android and iOS Chrome still use this technology, as do every major class of link vendors from attribution through email.
Are Universal Links a type of deep link?
Yes and no. Universal Links in themselves are not universal deeplinks - they can't route through the install process for example. But when the user has the app, they can deeplink. Better to think about all links in terms of what they can and can't do, rather than classify URLs into "deeplinks" and "not deeplinks."
Many links exhibit the behavior to deeplink depending on whether the user has the app and the context (browser, application, OS, OS version etc.) Change the frame of thinking.
Tracking Universal Links
Throughout the below document I outline all the different aspects of Universal Links. It's important to call out that continueUserActivity will report the referring URL from a Universal Link, so you can use this to attribute opens.
Because a UL is not a normal link, if you have redirects, that will break it. Similarly, if you turn off redirects, then whatever website click server you have will never get hit. This is for a different discussion, but important to note.
Lots of helpful information I've curated below on Universal Links if you're interested.
URI Schemes
Most people are familiar with URI schemes. A URI is a Universal Resource Indicator (link). URIs can be allocated to mobile applications. Typing in a URI, like airbnb:// will attempt to locate the app resource Airbnb on the device.
Before Universal Links or App Links existed (that is, before iOS 9.3/Android 6.0), one would need to use a “custom URI scheme” and the route in the form of airbnb://d/listing/530250 to deep link a user to specific content in a mobile app (in this case a listing). However, this was not secure nor did it handle the case when a user did not have the app installed (there was no fallback). The way that most attribution partners (Appsflyer, Kochava, Button, Yozio, Branch etc.) would work is that they would provide a link that handled this.
When the user visits the page of this URL, there would be some javascript that would set a timer and then try to launch the URI Scheme from the browser with some simple javascript:
window.location.href(...)
If the app didn’t open before the timer expired, then the vendor could assume the phone did not contain the app, and so instead, some javascript would fire to open the iTunes or Android URL instead. This mechanism relied on blocking javascript in the browser.
In iOS 9.3, Apple removed blocking javascript in Safari (link). The end result is that whenever you tried to open an app with a URI scheme in Safari, you would see a big error message that said, “Cannot Open Page.” This was a terrible user experience and led to the enforcement of Apple’s new system, Apple Universal Links.
Apple Universal Links & Android App Links are essentially web URLs (e.g., https://www.airbnb.com/rooms/530250) which are intended to direct users to the optimal location on web or the app. They were intended to take users to mobile web if the user doesn’t have the app, but take the user to the exact content in the app if they do. On a mobile device, if the user follows a universal link and has our app installed, they may be directed to the app, otherwise the system will fallback and land the visitor on our mobile website (with a few exceptions -- see below).
For a link to be truly Universal, it requires that the linked feature is enabled on web, iOS and Android and for all apps to share the same resource path.
Apple Universal Links & Android App Links
Apple Universal Links (iOS) and Android App Links (Android) are essentially the same concept, but are often interchanged, or confused with other routing mechanisms. It’s important to be explicit when you talk about these concepts, else you risk confusing or confounding different technologies which operate very differently.
Specifically, Apple Universal Links are a standard from Apple that is deployed on the iPhone operating system (OS), which allows a user to tap a link and be delivered immediately to the app if they have it. Apple Universal Links do not have redirects. It is a special system setup with some degree of technical complexity. When the user taps the link, a roundtrip server call is made to Apple and the OS opens the app immediately without ever opening the browser or loading the URL. More about how this works below.
Android App Links is the equivalent linking system that is setup on Android.
Universal Links start by hosting an “Apple App Site Association File” (AASA) for each of your domains.
It’s important to note that almost every company’s AASA is hosted at their main domain followed by “/apple-app-site-association”
Some examples:
https://www.jet.com/apple-app-site-association https://www.pinterest.com/apple-app-site-association
If you click these URLs, it will download the company’s AASA. An AASA example is on the right hand side. Some notable things included in an AASA: AppID for all the apps where Universal Links can be applied. In ours and many other AASA’s you will see setup for the production and test versions of the app so that links will work across all versions for testing. The AppID is structured as the App Prefix, followed by the Bundle ID. Usually each test version of the app has a different prefix, but the Bundle ID stays consistent.
Example... {App Prefix}.{ Bundle ID }
Paths: These are the pathways that will open up the app immediately if the user has it. The app will receive the referring URL and can parse out the proper pathway to deeplink the user to content there-after.
Most attribution vendors, like Branch or Appsflyer, also can host an AASA for you in certain cases (example: Branch’s AASA for Airbnb is hosted on the custom domain https://abnb.me/apple-app-site-association).
These files effectively whitelist and blacklist the URLs to map, or not map, to in the app. Just like with a company-owned AASA, for each domain, the vendor specifies the App IDs and the URL paths such as:
5LL7P8E8RA.com.airbnb.app
"/rooms/*"
"/wishlists/*"
"/invite"
"NOT /rooms/*/building-rules"
When users install or upgrade our app, iOS fetches the AASA files for all domains listed in our app’s entitlements to make sure that our websites allow our app to open URLs on their behalf.
Known Problems with Universal Links
Universal Links work great in most cases, however these can easily and, inadvertently, be disabled! If this happens the user will always be redirected to the website URL until they upgrade their app or reset what we call their “Entitlements File” (link).
If a user taps on the ‘airbnb.com’ or ‘abnb.me’ link in the top-right of our app, the OS will direct the user to the website, but it will also permanently direct any future Universal Link to the mobile website for links with that domain!
This effectively breaks the functionality of Apple Universal Links for the user. This isn’t trackable right now and the only way to reset is to long press the URL and click “Open in “Airbnb”” (not intuitive) or to tap the “Open” button on the Apple Universal Links Banner (Phantom Banner) that was described earlier in this document.
Apple Universal Links Banner
These AASA paths are also used to determine when to display, or not display, the iOS system’s “Universal Links Banner.”
This is a particularly hot topic that arises in conversations often and is worth discussing.
When you enable Apple Universal Links on a particular domain, Apple will inject a system App Banner on the Safari Browser. This means that in addition to whatever banners or web interstitials we display, Apple will also force a non-customizable, non-trackable Universal Links banner, that displays at the top of Safari for users who have the app and are viewing a URL in Safari who’s path is in the AASA.
We have no control over how this banner looks. We can only determine if it should be visible on a page based on the AASA. We also currently have no way to identify if or when a user taps the ‘OPEN’ button (IE no attribution.
Summary of Apple Universal Links Banner Attributes:
- ONLY displayed if the user has the app.
- NOT the same as the Apple Smart App Banner
- ONLY displayed on iOS Safari Browser.
- Not customizable, except, you can customize the text of the title and description in this banner with the The iTunesMetadata.plist Contents (link).
- No attribution or tracking.