Deep Linking for Mobile Apps: The Practical Guide

A mobile deep link has to handle two completely different users with one URL: the person who has your app installed and the person who does not.

Get the second case wrong and the tap lands on a generic App Store page instead of the screen you promised — and at the platform median of $3.80 per tracked click (TrackRev platform data, Q2 2026), every misrouted tap is paid-for traffic wasted.

Deep linking is the set of techniques that make one link do the right thing in every case.

This guide explains the three kinds of mobile deep link, how deferred deep linking rescues the not-installed user, and the fallback chain that keeps a single URL working across app, store, and desktop.

It is also honest about what quietly breaks deep links in 2026 — in-app browsers and privacy-driven parameter stripping — because a deep link that works in testing and fails inside an Instagram webview is worse than no deep link at all.

Tracked properly, each deep link also ties its taps back to the channel behind each install.

Why this matters for your revenue

The gap between a tap and the right screen is where mobile revenue leaks.

Someone taps a link to a specific product, offer, or piece of content; if the deep link only works for users who already have the app, everyone else lands on a home screen or a bare store listing and has to find their way back to what they wanted — most will not.

That drop-off is invisible in a click report, because the click counted; it is the intent behind the click that was lost.

Deferred deep linking is the mechanism that recovers the not-installed cohort, and for a growing app that cohort is the majority.

Routing a new install to the exact screen they were promised — the shared playlist, the referred workspace, the discounted plan — is the difference between an install that activates and one that opens once and never returns.

When the deep link is also tied to revenue attribution, you can finally see which campaigns drove installs that turned into paying customers, rather than just which drove downloads.

Installs are a vanity metric; installs that convert are the real one.

The three kinds of “deep link”

“Deep link” is used loosely for three different mechanisms with very different behaviour when the app is not installed. Getting them straight is the whole foundation.

Standard deep links (custom URI schemes)

The original form: a custom URI scheme like myapp://product/123 that the operating system routes to your app.

It works cleanly when the app is installed, but it has a fatal weakness — if the app is not installed, the link has nowhere to go and the user sees an error or nothing at all.

Custom schemes also cannot be clicked reliably from many contexts because they are not standard web URLs. They still have uses inside an app, but they are the wrong choice for links shared with the outside world.

Universal Links (iOS) and App Links (Android)

The modern form uses ordinary https:// URLs that open your app when it is installed and your website when it is not. Because they are real web links, they degrade gracefully — a not-installed user simply gets the web page.

This is the mechanism you want for anything shared publicly, and it is platform-specific in how it is set up.

How Universal Links work

On iOS, a Universal Link is an https:// URL on your domain that iOS associates with your app through an apple-app-site-association file hosted on that domain.

When a user taps the link and your app is installed, iOS opens the app to the matching screen; if not, Safari opens the web URL.

The association file is what authorises your app to claim those URLs, which is why Universal Links cannot be spoofed by another app.

How App Links work

On Android, App Links are the equivalent: https:// URLs verified through a Digital Asset Links file (assetlinks.json) on your domain.

Once Android verifies the association, tapping the link opens your app directly instead of showing a chooser; without the app, the link opens in the browser.

As on iOS, the hosted verification file is what ties the domain to the app and prevents another app from hijacking your links.

Deferred deep linking

Deferred deep linking solves the case Universal Links do not: the user does not have the app, installs it, and should still land on the screen they originally tapped.

The click is remembered, the user is sent to the store, and on the app’s first launch the remembered destination is retrieved and the user is routed there.

Without deferral, every new install lands on a generic first-run screen and the original intent is lost. Deferral is what makes an install-first journey feel continuous.

The fallback chain: one URL, every outcome

A production deep link is really a decision tree behind a single URL. The link resolver checks the situation and picks the branch.

App installed → open the screen

The happy path. The app is installed, the Universal Link or App Link association fires, and the operating system opens the app directly to the target screen with the parameters intact.

No store, no browser, no friction — the user taps a product link and sees that product inside the app a moment later.

This is the case every mechanism handles well; it is the other branches that separate a robust deep link from a fragile one.

App not installed → store, then deferred deep link

When the app is absent, the link sends the user to the correct app store, and a deferred deep link carries the original destination across the install.

On first launch, the app reads that stored destination and routes the user to the screen they wanted, not a generic welcome page.

This branch is where most home-grown deep-link setups fail, because remembering the destination across an install requires a resolver and a matching step that raw Universal Links do not provide.

Desktop and unsupported clients → web fallback

Not every tap happens on a phone.

A desktop click, an unsupported browser, or a client that blocks the app handoff should fall back to a sensible web page — ideally the web version of the same content, so the intent still resolves.

A well-built deep link always has a web fallback as its floor, so no click ever dead-ends. The fallback URL is also what search engines and link previews see, which keeps the link well-behaved outside the app entirely.

Attributing the install to the click

The reason to route this carefully is not only UX — it is attribution.

If the click that led to an install is remembered, you can credit the campaign, channel, or referrer that drove it, and then connect that install to whatever revenue it eventually produces.

Without the deep-link resolver holding the click, installs arrive anonymous and every acquisition looks like “organic”, which is the mobile equivalent of the “direct” bucket swallowing your best channels.

Deep-link types at a glance

The three mechanisms, judged on the thing that matters most — what happens when the app is not installed.

What breaks mobile deep links in 2026

Deep linking is harder than the documentation suggests, because the real world includes in-app browsers and privacy features the happy-path guides skip. Two failure modes cause most of the pain.

In-app browsers and webview sandboxes

A large share of link taps happen inside another app’s in-app browser — the webview that opens when you tap a link in Instagram, TikTok, or a messaging app.

These webviews do not always honour the Universal Link or App Link handoff, so a link that opens your app perfectly from Safari may open a web page inside the social app instead, trapping the user in a sandbox.

The mitigation is detecting the in-app browser and prompting the user to open in the system browser, plus always having a solid web fallback so the sandboxed user still sees the right content.

iOS Link Tracking Protection and parameter stripping

iOS Link Tracking Protection strips known tracking parameters from URLs in Mail, Messages, and Private Browsing.

If your deep link relies on query parameters to carry the destination or the campaign, those can be removed before the link resolves, breaking both the routing and the attribution.

The durable approach is to keep the routing information server-side on your own tracking domain — resolve the click on the server, before the browser can strip anything — rather than depending on parameters surviving the trip.

This is the same first-party principle behind first-party link tracking after iOS 17.

Clipboard-based deferred matching and privacy changes

Older deferred-deep-link setups matched the install to the click using device fingerprinting or the clipboard.

Both have been curtailed: probabilistic fingerprint matching is restricted by platform privacy rules, and reading the clipboard now triggers a visible paste notification that users find alarming.

The reliable modern approaches lean on the platform’s own install-referrer mechanisms and first-party click resolution instead. If a deep-link tool still depends on clipboard matching, treat that as a warning sign rather than a feature.

Deep-linking approaches compared

The category ranges from full mobile-measurement partners to raw platform links you wire yourself. The honest positioning is that these solve overlapping but different problems.

TrackRev mobile deep links

TrackRev mobile deep links build the whole fallback chain into one branded link on your own domain: open the app if installed, route to the store and carry the destination across the install if not, and fall back to the web on desktop and unsupported clients.

The click is resolved server-side, so it survives iOS Link Tracking Protection, and it feeds the same first-party data model as the rest of Link Tracking — so an app open ties back to the campaign that drove it and, through revenue attribution, to the revenue it eventually produced.

It is included on TrackRev's paid plans from $39/mo, with a free tier of 1,000 tracked events to test the routing.

On cost, the stack math is the honest close. The default setup pairs Bitly Growth (~$35/mo) for link tracking with Rewardful Starter (~$49/mo) for affiliates — $84+/mo across two tools with two different definitions of a conversion.

TrackRev is $39/mo for all three products on one data model. For content and marketing deep links tied to revenue, that is the whole job on one bill.

When NOT to use TrackRev for deep linking

TrackRev builds content and marketing deep links tied to first-party revenue attribution.

It is not a full mobile measurement partner: if your core need is programmatic user-acquisition measurement across many ad networks with SKAdNetwork and SAN integrations, fraud protection at ad-network scale, and MMP-grade cohort analytics, that is the Branch, AppsFlyer, or Adjust category and you should use one of those.

TrackRev’s deep links are the right tool when you want links that route correctly, fall back gracefully, and connect an app open to the marketing that drove it and the revenue it earned — without a separate MMP contract for a smaller app.