"Deep link" is the general term for any link that opens a specific screen inside an app. Universal Links (iOS) and Android App Links are the verified https:// way of building deep links, custom URL schemes are the older unverified way, and deferred deep links are the ones that still work when the person has to install the app first. The real choice is which mechanism opens your app, and whether the link needs to survive an install.
Here is how the four compare:
| Custom URL scheme | Universal Links | Android App Links | Deferred deep links | |
|---|---|---|---|---|
| Platform | iOS and Android | Apple platforms | Android 6 and later | iOS and Android |
| Looks like | myapp://offer/42 | https://example.com/offer/42 | https://example.com/offer/42 | Usually an https:// link on a link domain |
| Proof that you own the link | None | apple-app-site-association file on your domain | assetlinks.json file on your domain | Depends on the mechanism underneath |
| App installed | Opens the app | Opens the app directly | Opens the app directly, no chooser | Opens the app |
| App not installed | Fails, often with an error | Opens the same URL on your website | Opens the same URL on your website | Sends the user to the store, then delivers the destination on first open |
| Needs a server | No | Yes, to host the file | Yes, to host the file | Yes, plus an SDK in the app |
| Best for | App-to-app handoffs and as a fallback layer | Any link a person taps on iOS | Any link a person taps on Android | Referral, affiliate, advert and invite links |
For the basics, see our plain-English guide to what deep linking is. This post covers the differences and which to pick.
What is the difference between universal links and deep links?
A universal link is a type of deep link, so the two are not alternatives. Every universal link is a deep link, but not every deep link is a universal link. When people search for "universal links vs deep links", they almost always mean "Universal Links vs custom URL scheme links", because for years the custom scheme was the only kind of deep link there was.
The practical differences are the address (a prefix you invent, such as myapp://, against an ordinary web address on a domain you own), ownership (nobody checks who registered a custom scheme, while a universal link is verified against your website), and what happens without the app (a custom scheme link has nowhere to go, while a universal link is still a working web page).
Apple is direct about which it prefers. Its documentation on defining a custom URL scheme says that while custom URL schemes are "an acceptable form of deep linking, universal links are strongly recommended".
What does "universal deep linking" mean?
"Universal deep linking" is not an official term. It is used as a loose name for Apple's Universal Links, and for a single link that works everywhere (iOS and Android, app installed or not). The second meaning is really a deferred deep link built on Universal Links and App Links, covered further down.
Custom URL scheme vs Universal Links: what changes on iOS?
On iOS, moving from a custom scheme to Universal Links changes who can claim your links, what users see without the app, and how much you set up.
Who can claim the link
With a custom scheme, anyone can. Apple's documentation states that using a reverse-DNS style identifier is good practice but "doesn't prevent other apps from registering the same scheme and handling the associated links", and that if several apps register the same scheme, "the app the system targets is undefined".
With Universal Links, only you can. When someone installs your app, the system checks a file on your web server to confirm that your website allows the app to open its URLs. As Apple's guide to allowing apps and websites to link to your content puts it, only you can store that file on your server, which secures the association.
What users see when the app is missing
A custom scheme link is not a web address, so a phone without the app cannot do anything with it. A universal link is described by Apple as one URL that "works for both your website and your app": if the person has not installed the app, the system opens the URL in their default browser and your website handles it.
What you have to set up
A custom scheme is a few lines in your app's configuration and nothing else. Universal Links need two things that must agree with each other:
- An
apple-app-site-associationfile (no file extension) in the.well-knowndirectory of your website, listing your app and the paths it handles. - The Associated Domains capability in your app, with an
applinks:entry for the domain.
Apple's guide to supporting associated domains adds some details that catch teams out. The file must be hosted over https:// with a valid certificate and with no redirects. Each subdomain needs its own entry and must serve its own file. And since iOS 14, devices request the file from an Apple-managed content delivery network rather than your server, which Apple says requests your file within 24 hours, with devices checking for updates roughly once a week after install. A change to the file is therefore not instant.
Where Universal Links behave differently
If a user is browsing your website in Safari and taps a universal link on the same domain, Apple keeps them in Safari, "respecting the user's most likely intent to continue within the browser". A link to a different domain opens the app. Custom schemes have no such rule, which is one reason they have not disappeared.
App Links vs Universal Links: are they the same thing?
Android App Links and Universal Links do the same job on different operating systems. Both are standard https:// links, both rely on a file on your website to prove ownership, and both fall back to the web page when the app is not installed. Most apps on both stores set up both on the same domain and paths, so one link works on either phone.
The differences are in the detail:
| Universal Links | Android App Links | |
|---|---|---|
| Verification file | /.well-known/apple-app-site-association | /.well-known/assetlinks.json |
| Identifies the app by | App identifier (Team ID plus bundle identifier) | Package name plus signing certificate fingerprint |
| Declared in the app with | Associated Domains capability | Intent filter with android:autoVerify="true" |
| Unverified version | No equivalent for https:// links | Plain deep link, which can show a chooser |
| Supported on | Apple platforms | Android 6 and later, on devices with Google services |
Android has a middle tier that iOS does not
On Android, "deep link" has a specific meaning. Google's App Links documentation separates two things:
- Deep links, a standard platform capability available on all Android versions. An app can register for custom schemes or for web domains, but these links are "subject to the system disambiguation dialog".
- Android App Links, which Google calls "an enhanced deep linking capability". Once verified, they open your app immediately, "without requiring the user to select your app from a disambiguation dialog".
So on Android, the question "deep links vs App Links" has a literal answer: an App Link is a deep link to your own website that has passed verification. Google's guide to creating deep links gives the order Android follows: open the user's default app for the link, or the only app that can handle it, or otherwise show the chooser. Verification lets you skip that last step.
Where do deferred deep links fit in?
Deferred deep links are not another mechanism competing with the other three. They are a behaviour added on top. "Deferred" describes what the link can do (remember its destination across an install), not how it opens the app.
Universal Links and App Links both stop at the same point. If the app is missing, the user gets your web page. If they then install the app from the store and open it, the app starts on its home screen with no knowledge of the link that brought them. A deferred deep link closes that gap: the link goes to a server that records the destination, the user is sent to the right store, and an SDK in the app asks for the destination on first launch.
On Android there is platform help for this. Google Play's Install Referrer API lets an app retrieve the referrer URL of its own install, along with when the referrer click happened and when the installation began. On iOS there is no equivalent hand-off from the store to the app, so the link platform keeps the details on its own servers and returns them when the new install checks in.
That is why deferred deep linking nearly always involves a service and an SDK. Our guide to deferred deep links and why they matter for app marketing goes through the mechanics and the use cases in full.
Which type of deep link should you use?
Start from who will tap the link and whether they already have your app.
| Situation | Use |
|---|---|
| Emails, push notifications and messages to existing users | Universal Links and App Links |
| Links on your own website that should open the app | Universal Links and App Links (remember the same-domain Safari rule) |
| One of your apps opening another, or a callback into your app from another app | Custom URL scheme, or Universal Links if you need the ownership guarantee |
| Sharing content, where some recipients will not have the app | Universal Links and App Links at minimum, deferred if the destination should survive the install |
| Referral, invite, creator, affiliate and paid advert links | Deferred deep links |
| QR codes on packaging or print | Deferred deep links, since you cannot know who has the app |
The short version
- Use Universal Links and App Links as your baseline. They are what both Apple and Google recommend, they cannot be claimed by another app, and they degrade to a working web page.
- Add deferred deep linking when links reach people without the app. That is the point at which the destination, and often the identity of whoever shared the link, has to make it through the store.
- Keep a custom URL scheme as a supporting layer. Do not put one in a marketing email or a social post.
Do you still need a custom URL scheme?
Often, yes, but not as the link you hand to people. Custom schemes remain useful for app-to-app communication and as a way into the app when a verified link is not available. Because a scheme can be registered by any app, Apple advises validating every parameter in an incoming URL and limiting what such links are allowed to do.
Should you build deferred deep links yourself or use a platform?
Universal Links and App Links are free platform features that need nothing but a web server. Deferred deep linking is different, because someone has to run the server that remembers each tap and the SDK that collects it on first open.
The options are Insert Links (the deferred deep links built into Insert Affiliate), general-purpose link platforms such as Branch and AppsFlyer, or your own build. Which makes sense depends on what the links are for:
- If the links exist to credit sales to affiliates, creators or referring users, you need the link and the commission tracking to share one identifier. Insert Affiliate does this with Insert Links. Each affiliate gets a link that detects iOS or Android and whether the app is installed. If it is, the link opens the app and credits future sales to that affiliate. If not, the user goes to the App Store or Google Play, and on first open the SDK remembers which affiliate referred them.
- If you already run a link platform for campaigns, you do not have to replace it. Insert Affiliate can read the affiliate from links created in Branch, AppsFlyer or another deep linking platform.
- If you build it yourself, budget for keeping the install-time hand-off working on both stores as operating systems change.
Insert Links also show how these mechanisms stack rather than compete. The minimum setup is a custom URL scheme. Universal Links and App Links are an optional, recommended step on top: you add your Apple Team ID and Android SHA-256 certificate fingerprint in the dashboard and add the link domain to your app, and installed users then go straight into the app without the browser loading first. The deferred behaviour sits above both. The Insert Links setup guide shows each layer.
Frequently asked questions
Are universal links the same as deep links?
Not quite. A universal link is one kind of deep link: Apple's verified https:// kind. "Deep link" also covers custom URL scheme links, Android App Links and deferred deep links. When the two are contrasted, "deep link" usually means the older custom scheme style.
What is the Android equivalent of Universal Links?
Android App Links. They are https:// links verified through an assetlinks.json file on your domain, and once verified they open your app without the "Open with" chooser. They are supported on Android 6 and later on devices with Google services.
Do universal links work if the app is not installed?
They work as web links. The same URL opens in the browser and your website handles it, so the user is not left with an error. What they do not do is carry the destination through an install, which is the job of a deferred deep link.
Can one link be a universal link and a deferred deep link at the same time?
Yes, and good ones usually are. The link is an https:// URL that opens the app directly through Universal Links or App Links when the app is installed, and falls back to a store redirect with a first-open lookup when it is not. The user only ever sees one link.
Do I need a deep linking platform for Universal Links and App Links?
No. Both are built into the operating systems and only need a file on your website and a setting in your app. A service becomes useful when you need deferred deep linking, one link that routes by device, or data such as a referral or affiliate code carried through the install.
Next step
Mark each link your app sends today against the table at the top. Anything still on a bare custom scheme that a person taps should move to Universal Links and App Links first. Anything that reaches people without the app, especially links that decide who gets paid, needs to be deferred. If those links are for affiliates or referrals, Insert Affiliate is free to start, and our guide to tracking affiliate revenue in mobile apps covers what happens after the link has done its job.