What Is Deep Linking? How It Works on iOS and Android

$ cat table-of-contents

1. What is a deep link?
2. What are the three linking mechanisms?
3. How do Universal Links and App Links actually work?
4. What is the difference between deep links, deferred deep links, and contextual deep links?
5. Why do deep links break?
6. What are deep links used for?
7. How do you implement deep linking?
8. How does deep linking affect install attribution?
9. Where LinkTrace fits
10. Frequently asked questions

What is a deep link?

Definition: A deep link is a link that takes a user to a specific location inside a mobile application, rather than to a web page or to the app's default home screen. The "deep" refers to depth inside the app's content: a particular product, a promo screen, a friend's profile, a specific household or group, instead of the front door.

A normal web link has one job: open a page in a browser. A deep link has a harder job. It has to answer three questions in sequence:

1. Is the app installed on this device?
2. If yes, which screen inside the app should open?
3. If no, where should the user go instead?

Question 3 is where most naive setups quietly fail, and it is the reason an entire category of linking infrastructure exists. More on that in the sections on breakage and deferred deep linking.

The idea is older than the current tooling. Early iOS and Android apps used custom URI schemes like myapp://promo/SAVE20. In 2015 both platforms shipped the modern replacement: Universal Links with iOS 9, and App Links with Android 6.0 (Marshmallow). Both let an ordinary https:// URL open an app directly, which is what deep linking means in practice today.

What are the three linking mechanisms?

"Deep link" gets used loosely for three different mechanisms. They behave differently, especially in the failure cases, and conflating them is the source of most deep linking bugs.

The two modern mechanisms share one design: the link is a real HTTPS URL, and the operating system only hands it to your app after cryptographically verifying that your app and your domain belong together. That verification is what killed the URI scheme as a serious option: anyone could register myapp://, so nothing stopped a rival app from hijacking your links.

How do Universal Links and App Links actually work?

Both platforms run the same three-part pattern, with different file names:

1. You publish a verification file on your domain. On iOS this is the apple-app-site-association (AASA) file, served over HTTPS at https://yourbrand.com/.well-known/apple-app-site-association (or at the root). On Android it is assetlinks.json at https://yourbrand.com/.well-known/assetlinks.json.
2. Your app claims the domain. On iOS you add an Associated Domains entitlement (applinks:yourbrand.com) in Xcode. On Android you add an auto-verified intent filter for your domain in the manifest.
3. The OS checks the pair at install time. When the app is installed (or updated), the OS downloads the verification file and confirms it names this app. Only then does tapping your HTTPS link open the app. If verification fails, the link silently behaves as an ordinary web link - which is why half of all "deep links don't work" reports trace back to a mismatch between the app and the file: wrong Team ID, wrong SHA-256 fingerprint, wrong subdomain, or the file not being served with the right content type.

Two behaviors follow from this design and are worth internalizing:

• The browser fallback is real but limited. Without the app, a Universal Link or App Link opens the URL in the browser. Whatever that page shows is your entire safety net for non-installed users, unless you add deferred deep linking.
• Verification is per-domain. The association is tied to the exact host that serves the file. Change your link domain and you redo the pairing; use someone else's domain and you depend on their file.

What is the difference between deep links, deferred deep links, and contextual deep links?

These three terms describe what happens to the destination data, not three different link formats. The same https://yourbrand.com/promo/SAVE20 URL can be any of the three; what makes it standard, deferred, or contextual is what the infrastructure around the link does when someone taps it.

Contextual is less a third link type than a property the other two can have. A standard link can carry a promo code in its query string; a deferred link can carry the referrer's user ID through the install. The data usually travels as URL parameters, is recorded server-side when the link is tapped, and is handed to the app at open (or first open). This is where deep linking stops being navigation and starts being measurement: the same parameters that route the user also tell you which campaign, share, or invite brought them, which is the connection to attribution covered later in this post.

The mechanics of why the deferred case is hard - the install severs the connection between the click and the first app open, and someone has to reconstruct it - are covered in depth in Deferred Deep Links vs Deep Links and the implementation breakdown. The short version: deferred deep linking is the hard problem; standard deep linking is a solved one, provided your verification files are right.

Why do deep links break?

Four failure modes account for nearly all broken deep links in the wild:

• The app is not installed. A standard deep link cannot help this user at all. This is the deferred case above, and the single biggest source of lost invites and referrals.
• In-app browsers. Links tapped inside Instagram, TikTok, or Facebook usually open in the host app's embedded browser, where the operating system never sees the tap the way it needs to - and Universal Links and App Links never fire. The full mechanics and workarounds are in our in-app browsers post.
• URI scheme fragility. Custom schemes have no fallback, no ownership proof, and produce dead ends or error dialogs when the app is missing. This is the legacy mechanism for a reason.
• Verification mismatches. A wrong Team ID, a rotated signing certificate, a subdomain that does not match character-for-character, or an AASA file served with the wrong content type all make the OS quietly treat your app link as a web link. Both platforms verify at install time, so fixing the file does nothing until users reinstall or update.

What are deep links used for?

Every serious mobile growth motion eventually needs links that land users somewhere specific:

• Referrals and invites. The inviter shares a link; the new user should land in the right group, household, or challenge - including after a fresh install. This is the use case behind referral tracking.
• Personalized onboarding. A contextual deep link can carry the campaign or promo that brought the user, so the first session matches what they tapped.
• Re-engagement. Email, SMS, and push campaigns linking straight to the relevant screen instead of the home screen.
• Paid and organic social. Bio links and posts that should open the app when it is there; see the organic social attribution guide for the measurement angle.
• QR codes and offline. Posters and packaging that scan into a specific in-app destination.

How do you implement deep linking?

At the platform level, the work is the three-part pattern from earlier, done twice:

• iOS: add the Associated Domains capability in Xcode with an applinks:yourdomain entry, and serve the AASA file over HTTPS from that domain.
• Android: add an auto-verified intent filter for your domain in the manifest, and serve assetlinks.json signed with your app's certificate fingerprint. App Links require Android 6.0 or later on devices with Google services.

Then test on real devices, because both platforms have traps the simulator hides. On Android, adb shell pm get-app-links your.package shows the verification state and adb shell am start -a android.intent.action.VIEW -d "https://yourbrand.com/r/abc" your.package simulates a tap. On iOS, tap a real link from Notes or Messages - pasting the URL into Safari's address bar does not trigger Universal Links. And after any change to the verification file or the app side, reinstall: verification runs at install time.

The build-vs-buy question is less about the checklist above and more about everything around it: who hosts and maintains the verification files, what happens for users without the app, how links get created and branded, and how you know which links drove installs. Rolling your own covers the first item well and leaves the rest as follow-on projects; the build-vs-buy breakdown prices that honestly.

How does deep linking affect install attribution?

Deep linking and attribution answer different questions that meet at the same link:

• Deep linking: where does the user land?
• Attribution: which link, campaign, or person gets credit for this install?

The connection: a link tap and an app install are two separate events, often minutes or hours apart, with an app store visit in between that severs the trail. On Android, the Play Install Referrer can carry one referrer value through a Play Store install exactly. Everywhere else - iOS entirely, and Android installs that arrive through browsers, in-app browsers, or other stores - someone has to match the recorded click to the fresh install after the fact. That matching layer is what turns "links that route well" into "links you can measure", and it is why deep linking and install attribution are usually built or bought together.

Where LinkTrace fits

LinkTrace is built for teams that want the whole chain - routing, deferred behavior, and attribution - without shipping an SDK:

• One link, both platforms. Links are ordinary HTTPS URLs that detect the device and route to the App Store or Play Store when the app is missing. Integration is two HTTP calls from your backend, covered in the API reference.
• Deferred deep linking on every plan. A screenName and context ride in the link's customPayload and come back on first launch after signup, so new installs land on the intended screen. Matching uses device fingerprints inside a 24-hour window - probabilistic, and honest about it: outside the window the API returns attributed: false.
• Verified app-opening links without the plumbing. On the Scale plan, links live on your branded subdomain and LinkTrace hosts the AASA and assetlinks.json verification files for you - the app side is a one-line iOS capability and a few Android manifest lines, per the setup guide.
• Measurement built in. Link-wise click counts on every plan, an analytics dashboard from Growth, so the same links that route also report.

The product side of this, with plan details, lives on the deep linking product page.

Frequently asked questions

What is the difference between a deep link and a normal URL?

A normal URL opens a page in a browser. A deep link opens a specific screen inside an app. The modern forms - Universal Links and App Links - are normal HTTPS URLs that the operating system redirects into the app when it is installed and verified, so one link serves both cases.

Do deep links work if the app is not installed?

A standard deep link does not. Universal Links and App Links fall back to opening the URL in the browser, but nothing carries the destination into a later install. Covering the not-installed case is deferred deep linking, a separate mechanism that matches the click to the install after the fact.

Does deep linking require an SDK?

Not inherently. The platform mechanisms themselves are entitlement and manifest entries plus hosted verification files - no vendor SDK. Tools differ: some deep linking platforms integrate through an SDK, others (LinkTrace included) work through server-side API calls with no SDK in the app.

Why does deferred deep linking need a third-party service?

It does not strictly need one, but the DIY version is real infrastructure: you must record clicks server-side, match them to installs across browsers and stores, handle the iOS and Android differences, and maintain it as platforms change. On Android, the Play Install Referrer gives you the exact-referrer transport for Play installs only. A link layer packages the rest. The build-vs-buy trade-offs are laid out in the implementation guide.

What happened to Firebase Dynamic Links?

Google shut it down on 25 August 2025; every link now returns a 404. Teams that relied on it had to move to alternatives - a sourced comparison is in Firebase Dynamic Links Alternatives.

What is the best deep linking platform?

It depends on the job. Branch is the enterprise incumbent with MAU-metered pricing and no published prices. AppsFlyer's OneLink comes with a full MMP. For teams that want deep linking, deferred deep linking, and install attribution without an SDK and at a flat published price, that is the gap LinkTrace fills. The honest answer is to match the tool to whether you also need paid-ad measurement (an MMP) or not.

If you remember three things

• A deep link opens a specific screen in your app. Today that means Universal Links on iOS and App Links on Android - HTTPS URLs the OS hands to your app after verifying your domain pair.
• Standard deep links stop at the install. Users without the app are the deferred case, and that matching problem is the hard part of the stack.
• Routing and measurement live on the same link. Choose infrastructure that answers both "where does the user land" and "which link gets credit" - or plan to build both.

Sources

Platform behavior in this guide was checked against the following pages on 22 October 2026.

• Apple: Supporting associated domains
• Android: About App Links and Verify App Links
• Android: Android 6.0 APIs (App Links availability)
• LinkTrace: Enable Deep Linking, Deferred Deep Linking, API Reference

---

LinkTrace is a deep linking and install attribution service for startups and app developers. Two HTTPS calls, flat pricing, no SDK. Create a free account or see the plans.

Related guides: Deferred Deep Links vs Deep Links, Universal Links vs App Links, Deep Links in In-App Browsers, and Google Play Install Referrer: The Complete Developer's Guide