Deep Link
A link that opens an app at a specific screen, not just its home page.
A deep link is a link that opens a mobile app at a specific screen instead of the app's home page. Tap a deep link to a product in the Amazon app and you land on the product, not the storefront. Tap one to a Spotify playlist and Spotify opens directly on that playlist.
For example: send a friend an Airbnb listing. Without deep linking, they tap the link, the browser opens, and they navigate to the listing from Airbnb's home page — losing them along the way. A deep link drops them straight into the Airbnb app at the listing.
The three kinds
The differences matter most when the app isn't installed.
Three kinds of deep links
myapp://product/42
- URL pattern
- Custom protocol (myapp://, fb://)
- Verified by OS?
- No — any app can register any scheme
- Fallback if app missing
- Browser shows error or does nothing
- Available since
- iOS 2.0, Android 1.0
- Use today?
- Legacy only — replaced by Universal/App Links
https://example.com/product/42
- URL pattern
- Standard https:// URL on your domain
- Verified by OS?
- Yes — via apple-app-site-association file
- Fallback if app missing
- Opens in Safari at the same URL
- Available since
- iOS 9 (2015)
- Use today?
- Default for iOS
https://example.com/product/42
- URL pattern
- Standard https:// URL on your domain
- Verified by OS?
- Yes — via assetlinks.json file
- Fallback if app missing
- Opens in browser at the same URL
- Available since
- Android 6.0 Marshmallow (2015)
- Use today?
- Default for Android
Universal Links and App Links are the same idea on different platforms — a regular https:// URL the OS routes to your app if it's installed, and to the browser if it isn't.
URL schemes were the original approach, but any app could register any scheme — and a tap on myapp:// with no app installed silently failed. Universal Links (Apple) and App Links (Google) solve both: the OS verifies your domain via a file you publish on it, and the same https:// URL falls back to the browser if no app is there.
Try it
The trickiest part is predicting what happens for every platform-and-install combination.
Try it — what happens when someone clicks?
Platform
App installed?
Opens the app at the linked screen.
OS recognizes the domain is associated with the app and opens it directly at the linked screen.
Loads in the browser unless the app has registered the domain as an Universal/App Link — in which case the OS will offer or auto-open the app.
How verification works
The OS verifies your domain owns the app via a small text file you publish on it:
- iOS —
apple-app-site-association(no extension) at/.well-known/on your domain. - Android —
assetlinks.jsonat the same/.well-known/location.
The OS fetches the file on install or update and remembers the association. Without it, the link falls back to the browser even with the app installed — the single most common cause of "works in development but not in production."
Deep links and short URLs
Two situations where putting a Nimble Links short URL in front of a deep link is genuinely useful:
- You're working with URL schemes. Schemes have no built-in fallback — a
myapp://link silently fails on desktops, on platforms that don't recognise it, or when the app isn't installed. Wrap the scheme in a Redirect by Operating System link and you get one shareable URL that hands iOS its scheme, hands Android itsintent://URL, and sends desktops to a sensible web fallback. - The destination differs by platform. App Store on iOS, Play Store on Android, plain web on desktop — three separate links that need to live behind one URL you can put on a flyer, in a QR code, or in a social post. Redirect by Operating System handles that routing for you.
References
iOS verification is documented in Apple's Supporting Associated Domains guide; Android verification in Google's Verify Android App Links guide.