Key takeaways
- "Deep link" is the umbrella term for any URL that opens an app to a specific screen. A Universal Link (iOS) or App Link (Android) is a specific, verified kind of deep link that uses a real HTTPS URL instead of a custom scheme.
- The practical difference is verification and fallback: Universal Links and App Links are cryptographically tied to your domain and fall back gracefully to the web, while unverified custom schemes can be claimed by another app and simply fail if the app is not installed.
- Almost every production app should use Universal Links and App Links as the default, and reserve plain custom schemes for internal or development-only links.
The umbrella term problem
"Deep link" gets used two different ways in most conversations, and that ambiguity is where a lot of confusion starts. Sometimes it means any URL that opens an app to a specific screen, which is the broad, correct definition. Other times people use it to mean specifically a custom URL scheme, like myapp://product/123, as opposed to a Universal Link. Both usages are common; the trick is knowing which one is meant from context.
For clarity in this article, "deep link" means the umbrella category, and "custom scheme" refers specifically to the myapp:// style link, so the real comparison is custom scheme vs Universal Link and App Link.
What a custom scheme is
A custom URL scheme is the oldest form of mobile deep linking. Your app registers a scheme, such as myapp://, with the operating system, and any link using that scheme is a candidate to open your app. It requires no domain, no hosted verification file, and almost no setup, which is why it remains the fastest way to test routing logic during development.
The catch is that a custom scheme is unverified by design. Nothing stops another app from registering the same scheme, and if it does, the operating system may show the user a chooser dialog, or in some cases the wrong app could intercept the link entirely. There is also no fallback: if the app is not installed, a custom scheme link simply fails, with nowhere to redirect the user.
What a Universal Link or App Link is
A Universal Link on iOS, or an App Link on Android, is a standard https:// URL that has been cryptographically verified to belong to your app through a domain-ownership handshake, an apple-app-site-association file on iOS or an assetlinks.json file on Android, matched against a declaration inside your app. Once verified, the link opens your app directly, with no chooser dialog, and no other app can claim it.
The fallback behavior is the other major advantage. Because the link is a real HTTPS URL, if the app is not installed, it simply opens as a normal webpage instead of failing outright, which gives you a natural landing page to route the user toward installing the app.
Side-by-side comparison
| Custom scheme | Universal Link / App Link | |
|---|---|---|
| URL format | myapp://path | https://yourdomain.com/path |
| Verification | None | Cryptographic, tied to your domain |
| Can be hijacked by another app | Yes, in principle | No |
| Fallback if app not installed | Fails, no destination | Opens as a normal webpage |
| Setup required | App-side registration only | Hosted verification file plus app entitlement or manifest config |
| Works from a browser address bar | Inconsistently | Yes, as a standard link |
| Best use case | Internal testing, dev builds | Production marketing links, shares, notifications |
When each one is the right call
Custom schemes still earn their place early in development. They let you confirm your in-app routing logic, the part of the code that decides what screen a given path should open, before you add the extra layer of domain verification. Some teams also keep a custom scheme alongside their Universal Link for other apps that want to open yours directly, without going through the web fallback path.
For anything a user outside your app will actually click, an email, an ad, an SMS, a shared link, a QR code, a Universal Link or App Link should be the default. The graceful web fallback alone justifies it: a marketing link that fails outright when the app is not installed is a lost conversion, while one that lands on a sensible webpage is a recoverable one.
A common mistake: using only a custom scheme in production
The most frequent version of this mistake is a team that ships a custom scheme for a share feature or referral link, tests it successfully because they already have the app installed, and only discovers the fallback problem once real users without the app start clicking the link and hitting a dead end. Since a custom scheme has no web fallback, that failure is invisible until the analytics show a spike in clicks with no corresponding installs or opens.
Universal Links and App Links catch this by construction, since the URL always resolves to something, either your app or your website, which is one reason they have become the default recommendation rather than a nice-to-have.
Frequently asked questions
What is the difference between a deep link and a Universal Link?
Deep link is the general term for any link that opens an app to a specific screen. A Universal Link is a specific type of deep link on iOS that uses a verified HTTPS URL instead of a custom scheme, so it cannot be hijacked and falls back to a webpage if the app is not installed. Android's equivalent is called an App Link.
Should I use a custom scheme or a Universal Link?
Use a custom scheme for internal testing or development builds where verification overhead is not worth it yet. Use a Universal Link or App Link for anything a real user might click, such as marketing links, shared content, or notifications, since it offers a secure, verified link with a graceful fallback to the web.
Can a custom scheme be hijacked by another app?
Yes, in principle. Because custom schemes are not verified against domain ownership, another app can register the same scheme, and the operating system may present the user with a choice of which app to open, or in edge cases route the link to the wrong app entirely.
What happens if a Universal Link is opened and the app is not installed?
The link opens as a normal webpage, since it is a real HTTPS URL rather than a custom protocol. This is one of the biggest practical advantages over a custom scheme, which has no fallback and simply fails if the target app is not present on the device.
Building links that need to work whether or not the app is installed?
Ulinkly handles Universal Links, App Links, and the web fallback for you. Start free for up to 10,000 monthly active users at ulink.ly/pricing.
Sources
- Apple: Supporting associated domains: https://developer.apple.com/documentation/xcode/supporting-associated-domains
- Android Developers: Verify App Links: https://developer.android.com/training/app-links/verify-applinks