These three terms get used interchangeably and they are not the same thing. Getting them confused leads to links that work on your test device and fail for a third of your users.
The three mechanisms
Custom URL schemes — myapp://product/123
The original approach. Your app registers a scheme with the operating system, and any URL using it gets handed to your app.
Works when: the app is already installed.
Breaks when: it isn't. The OS has nothing to route the URL to, so the visitor gets an error page or a tap that appears to do nothing at all. There is no built-in fallback — the failure is silent and confusing.
Also: custom schemes cannot be verified. Any app can claim myapp://, which is both a security concern and a reliability one. Many in-app browsers block them outright.
Apple Universal Links — https://yourdomain.com/product/123
Apple's replacement, and a genuine improvement. A standard https URL that iOS associates with your app via an apple-app-site-association file hosted at /.well-known/ on your domain.
Works when: the app is installed — it opens directly, no browser flash.
When the app is not installed: the URL is just a web page, so the visitor lands somewhere useful instead of an error. This graceful degradation is the whole point.
Requires: hosting the association file over HTTPS, with the correct team and bundle identifiers, and no redirects on that path.
Android App Links — https://yourdomain.com/product/123
Google's equivalent. Same principle, different file: assetlinks.json, again under /.well-known/, containing your package name and signing certificate fingerprint.
Verified App Links open your app directly. Unverified ones may show a disambiguation dialog asking the user to choose, which adds friction and confuses people.
Side by side
| Custom scheme | Universal Links | App Links | |
|---|---|---|---|
| Platform | Both | iOS | Android |
| Format | myapp:// | https:// | https:// |
| App not installed | Error / dead tap | Opens web page | Opens web page |
| Domain verification | None | Required | Required |
| In-app browser support | Often blocked | Generally works | Generally works |
| Setup effort | Trivial | Moderate | Moderate |
Where each one breaks
Custom schemes break for everyone without the app — which, for an install campaign, is your entire target audience.
Universal Links break if the association file is missing, malformed, served without HTTPS, or behind a redirect. They also do not fire when the URL is typed directly into the address bar, or in some cases when navigating within the same domain.
App Links break if the signing fingerprint in assetlinks.json does not match the build. A common trap: Google Play App Signing re-signs your app, so the fingerprint in your file must be the one Play uses, not the one from your local keystore.
All three get unpredictable inside in-app browsers. Instagram, TikTok, and LinkedIn each behave slightly differently, and behaviour changes between versions.
What to actually use
For install campaigns — driving new users to download — you want a routing link that sends visitors to the App Store or Google Play based on device. Universal Links and App Links are irrelevant here, because by definition the app is not installed yet.
For re-engagement — existing users, email campaigns, notifications — you want Universal Links and App Links so the app opens directly on the right screen, with a web fallback for anyone who uninstalled.
For both from one URL, the link needs to check whether the app is installed and branch accordingly. That is genuinely hard to do reliably, because iOS and Android both deliberately limit an app's ability to detect other installed apps. Most implementations use a timing heuristic — attempt the app URL, and if the page is still visible after a short delay, fall through to the store.
Practical setup checklist
iOS Universal Links
apple-app-site-associationat/.well-known/, served as
application/json, no redirect, HTTPS only
- Correct
appIDinTEAMID.BUNDLEIDform - Associated Domains capability enabled in the app
- Test on a real device — the simulator is not reliable for this
Android App Links
assetlinks.jsonat/.well-known/, HTTPS, no redirect- SHA-256 fingerprint matching the signing key Play actually uses
android:autoVerify="true"on the relevant intent filter- Verify with Google's Statement List Generator and Tester
Both
- Test from inside Instagram or TikTok, not only Safari and Chrome
- Test with the app installed *and* uninstalled
- Define what happens on desktop
How Bridgly fits
Bridgly handles the install-campaign case: one short link that detects the device and routes to the App Store, Google Play, or a web fallback — including the in-app browser handling that trips up hand-rolled implementations.
Universal and App Link redirects use domains configured on each project, so existing deep-link setups keep working alongside install routing.
Start free · Read: what is a universal install link
The short version
- Custom schemes are legacy: no fallback, no verification, often blocked.
- Universal Links (iOS) and App Links (Android) are the modern
equivalents — verified https URLs that degrade gracefully.
- For install campaigns you want device-based store routing, not deep links.
- For re-engagement you want Universal/App Links.
- Test on real devices, inside in-app browsers, with the app both installed and
not.
Frequently asked questions
- What is the difference between a deep link and a universal link?
- A deep link is the general idea of a URL that opens a specific screen inside an app. A Universal Link is Apple's specific implementation: a standard https URL that iOS associates with your app through a file hosted on your domain. Universal Links are deep links, but not all deep links are Universal Links — the older custom-scheme approach, like myapp://, is also a deep link and behaves very differently.
- What are Android App Links?
- Android App Links are Google's equivalent of Apple's Universal Links: standard https URLs verified against your domain using an assetlinks.json file, which open your app directly when it is installed. Unlike custom URL schemes, they fail gracefully to the web page when the app is not installed.
- Why do custom URL schemes like myapp:// fail?
- A custom scheme only works if the app is already installed. If it is not, the browser has nothing to hand the URL to, and the visitor sees an error or a dead tap with no explanation. Custom schemes are also blocked or ignored by many in-app browsers, and cannot be verified as belonging to you, so any app can register the same scheme.
Read more
Fundamentals · 1 min read
Bitly vs Dub vs Bridgly: picking by job
Bitly shortens. Dub pays digital partners. Bridgly routes app installs and ties physical QR scans to attributed sales and commissions.
Fundamentals · 2 min read
Deferred deep linking, explained without the jargon
Deferred deep linking carries a destination across an app install, so a new user lands where they were headed instead of your home screen. Here is how the matching works, why it is never perfect, and when it is worth the setup.
Fundamentals · 1 min read
App Links vs Universal Links: what differs and what does not
Android App Links and iOS Universal Links solve the same problem with different plumbing. Here is what each verification file does, why you need both, and the mistakes that stop them verifying.