What is deep linking, and how do Universal Links and App Links work?
What is deep linking? A deep link opens one screen in an app. Compare Universal Links, Android App Links and deferred links, with setup steps and fixes.
Muzahid Maruf, FounderUpdated
On this page
Explore with AI
Opens this article inside the chosen assistant with a ready-made prompt.
What is deep linking? It is the use of a link that opens a specific destination, such as the screen for product 123 in a mobile app, instead of the app's start screen or the site's home page.
Such a link is a deep link, or deeplink.
The phrase has 2 meanings.
On the web, Wikipedia defines it as a hyperlink to a specific piece of content, such as example.com/path/page, and calls a 1996 Scottish case, The Shetland Times against The Shetland News, probably the earliest legal dispute over such links.
In mobile development it means a link that opens a screen inside an app. Modern iOS and Android deep links are often ordinary https URLs, so the 2 meanings now overlap.
Key takeaways
- A deep link opens one specific screen or page, such as /products/123. Apple Developer Documentation strongly recommends Universal Links over custom schemes, and Android Developers recommends App Links for your own website.
- From Android 12 (API level 31), unverified web links open in the browser, so verify every domain, and treat deferred routing as best effort: Google shut down Firebase Dynamic Links on August 25, 2025.
- A verified Universal Link or Android App Link opens the app without a request to your server, so a redirect log misses those taps.
What is deep linking in a mobile app?
Android Developers lists 3 types of deep link: custom deep links, web links and App Links. iOS offers 2: custom URL schemes and Universal Links.
| Type | Example | App installed | No app | Setup |
|---|---|---|---|---|
| Custom URI scheme | myapp://products/123 | Opens the app; on Android a chooser appears if 2 apps share the scheme | Nothing to open | Register the scheme in the app |
| Universal Links (iOS) | https://example.com/products/123 | Opens the app directly, skipping Safari and your website | Opens the URL in the default browser | apple-app-site-association file plus the Associated Domains entitlement |
| App Links (Android 6.0 and later) | https://example.com/products/123 | Opens the app with no chooser once the domain is verified | Opens in the browser | assetlinks.json (Digital Asset Links) plus android:autoVerify in the manifest |
| Deferred deep link | Any of the above | Same as that type | App Store or Google Play first, then the right screen on first launch | Install referrer or a vendor SDK, plus code in the app |
Behavior as described in Apple Developer Documentation and Android Developers guides, October 2026.
Apple Developer Documentation warns that when 2 apps register one scheme, the system's choice is undefined, so I would keep custom schemes for links between your own apps.
Universal Links on iOS
Apple's Universal Links documentation splits the setup into a file on your server and an Associated Domains entitlement in the app.
{ "applinks": { "details": [ { "appIDs": ["ABCDE12345.com.example.app"], "components": [{ "/": "/products/*" }] } ] }}| Requirement | What Apple specifies |
|---|---|
| File name | apple-app-site-association, with no extension |
| Transport | https with a valid certificate and no redirects |
| Subdomains | Each one needs its own file and its own applinks: entry in the Associated Domains entitlement |
| First fetch | Since iOS 14 and macOS 11, devices get the file from Apple's content delivery network, which requests it from your domain within 24 hours |
From the Supporting associated domains guide in Apple Developer Documentation, October 2026.
A Universal Link tapped in Safari on its own domain stays in Safari, so test from Apple Notes or Messages.
How long an iOS fix takes to land
Apple says its network requests the file within 24 hours and devices check for updates about once a week. A fix to the apple-app-site-association file made on day 0 can reach the network by day 1 and the last iPhones around day 8. Android 15 and higher is similar, at up to 7 days.
App Links on Android
App Links are web links the app has proven it owns through a Digital Asset Links file, so the system opens the app with no chooser.
Android Developers' guide to verifying App Links says to wait at least 20 seconds after installing a test build before checking the result with adb.
<intent-filter android:autoVerify="true"> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:scheme="https" android:host="example.com" android:pathPrefix="/products" /></intent-filter>[ { "relation": ["delegate_permission/common.handle_all_urls"], "target": { "namespace": "android_app", "package_name": "com.example.app", "sha256_cert_fingerprints": ["YOUR_SIGNING_CERTIFICATE_SHA256"] } }]| Android version | What changed for deep links |
|---|---|
| Android 6.0 (API level 23) | App Links arrive; installing an app whose filter sets android:autoVerify to true starts domain verification |
| Android 11 (API level 30) and lower | The app becomes the default handler only if a matching assetlinks.json exists for every host in the manifest |
| Android 12 (API level 31) | A web link opens in your app only if the app is approved for that domain; otherwise it opens in the default browser |
| Android 12 (API level 31) and higher, for testing | adb can re-run verification by hand, and an app that targets a lower version can opt in with compat change 175408749 |
| Android 14 (API level 34) and lower | No background re-verification, so file changes are usually picked up at install or update |
| Android 15 (API level 35) | Domains are re-verified in the background, with changes taking up to 7 days to reach devices, and Dynamic App Links let an app adjust URL matching without a new release |
From the Android Developers deep links and App Links verification guides, both last updated October 1, 2026.
Deferred deep links
A deferred deep link survives the install, landing a new user on the linked screen at first launch.
On Android, the Play Install Referrer API gives the app the referrer URL of the install, the click timestamp and the install start time. It needs Google Play version 8.3.73 or later on the device.
Google's guide, last updated February 26, 2026, says the data stays available for 90 days and the sample uses client library 2.2, and an app should call it once, on its first run after installation.
Teams usually carry the destination in the referrer parameter of the Play Store link and read it back through the API.
https://play.google.com/store/apps/details?id=com.example.app&referrer=screen%3Dproducts%2F123Apple's documentation describes no step that carries a link through an App Store install, so on iOS a vendor or your own code does it.
Firebase Dynamic Links offered that handoff until Google shut it down on August 25, 2025, after which clicked links return a 404 and calls to its Short Links API return a 400 or 403.
Google's deprecation FAQ cites platform changes that made a stable post-install transition hard to deliver. I treat deferred routing as best effort, with a web page behind it.
Why deep links fail
Test 4 cases besides the installed app: a phone without the app, an Android 11 phone next to an Android 12 one, a desktop browser, and a tap inside Instagram, where in-app browsers can block the handoff.
| Symptom | Likely cause | First check |
|---|---|---|
| A chooser on Android 11, the browser on Android 12 | The app is not verified: assetlinks.json is missing, or the package name or SHA-256 fingerprint is wrong | Run adb shell pm get-app-links com.example.app |
| iPhone opens Safari | apple-app-site-association is missing, redirects, or lists the wrong app ID | Confirm the URL returns JSON directly, not a 301 or 302 |
| A fix changes nothing | Association files refresh on a schedule | Allow about 8 days on iOS and up to 7 days on Android 15 and higher, then reinstall the app on a test device |
| The campaign parameter never arrives | iOS 17 Link Tracking Protection can strip known tracking parameters in Messages, Mail and Safari Private Browsing | Put the campaign in the URL path, as the iOS 17 link tracking post explains |
How tracking works with deep links
A tracked URL on your own domain logs the click on the server, then sends a 302 redirect. A verified Universal Link or Android App Link skips that request, so the app must report the tap.
Worked example with made-up numbers
Suppose 1,000 people tap a campaign link and 600 of them already have the app. The redirect log records only the 400 taps from phones without it. If 3% of those 400 buy, the log shows 12 purchases from 400 clicks, a 3.0% rate. If 12% of the 600 app users also buy, that is 72 more purchases the log never saw, so the campaign really produced 84 purchases from 1,000 taps, or 8.4%. Without the app's side, the channel looks 2.8 times weaker than it is, and at $50 a purchase it never gets credit for $3,600 of revenue.
Setting up deep links with TrackRev
TrackRev's mobile deep links host the files above.
In the Mobile App Links section of the Domains settings you enter your iOS app ID, Android package name and SHA-256 fingerprints, and TrackRev serves apple-app-site-association and assetlinks.json on each verified custom domain.
Each link can carry separate iOS, Android and desktop destinations, so a tap without the app reaches the App Store or Google Play (see device-targeting redirects).
It syncs revenue from Stripe, Polar, Lemon Squeezy and Paddle, so App Store and Google Play purchases are not included.
No SDK goes in your app, so deferred routing or ad-network install measurement belongs with a vendor such as Adjust, AppsFlyer or Branch.
The free plan covers 50 links and 1,000 tracked events a month, and revenue figures start on Starter at $39 a month (pricing).
Found this useful? Share it.
Frequently asked questions
- Deep links are URLs that go to one item, such as /products/123, instead of a front page or start screen.
- Deep link is the general idea. Universal Links are Apple's verified https links, and App Links, available since Android 6.0, are Android's, checked through assetlinks.json.
- Universal Links and App Links fall back to the URL in a browser. A custom scheme has nothing to open, and reaching the right screen after an App Store or Google Play install takes deferred deep linking.
- Deferred deep linking remembers the tapped link, sends a person without the app to Google Play or the App Store, then opens the intended screen on first launch. Android has the Play Install Referrer API; iOS needs a vendor SDK.
- Not for Universal Links or App Links, which need an association file and app code that reads the URL. Deferred deep linking usually does need an SDK.
- Treat every parameter as untrusted input; Apple Developer Documentation calls custom URL schemes a potential attack vector.
Written by
Founder, TrackRev.io & Contant.io
Muzahid Maruf is the founder of TrackRev.io and Contant.io. He writes about marketing attribution, link tracking, and revenue analytics for SaaS teams.
Writes about Marketing attribution · Link tracking · Revenue analytics · SaaS growth
Stop guessing where your revenue comes from.
Set up TrackRev in about five minutes. The free plan covers 1,000 events a month, no card needed.
Start free