You built a referral program, sent the link to a friend, and they installed your app. But instead of landing on the invite screen, they hit your home page. The referral credit vanished. That broken handoff between a link and the right screen inside your app is a deep linking problem.
This article explains what deep linking is, the five types you need to know, and how to choose the right setup for your app. You will learn which links survive the App Store install gap, which tools can replace Firebase Dynamic Links, and what current privacy requirements affect your setup.
Email, SMS, and in-app referrals work better when links send people to the right place. Deep linking is the infrastructure that makes those channels work. Without it, every share button, referral link, and re-engagement email routes users to a dead end.
Getting deep links right means the difference between a growth loop that compounds and a funnel that leaks at every handoff.
What a deep link does
Deep links send users to the exact screen that matches their intent. That keeps the handoff between a tap and the in-app destination intact. After this section, you will understand the core link types and when each one fits.
A deep link is a URL that opens your app and navigates to a specific screen. Instead of dropping someone on your home screen, it takes them directly to a product, a profile, a post, or an offer. Deep links bring users into your app from browsers, notifications, social media, and ads.
Standard web URLs already do this for websites. Deep links do it for native apps. The difference matters because mobile apps do not have a universal address bar. Without deep links, there is no way to point someone at a specific piece of content inside your app.
Five types you need to know
The first three types work when the app is already installed. The last two preserve the original destination through install.
- URI schemes (like myapp://product/123): The oldest type. Your app registers a custom prefix, and the OS routes matching links to it. The problem: any app can register the same scheme, creating a hijacking risk that another app can exploit. If the app is not installed, the user sees an error. These do not work without the app installed, do not preserve context through install, and do not carry campaign data. Avoid these as your primary link type.
- Universal Links (iOS): Standard HTTPS URLs that iOS intercepts and opens in your app. If the app is not installed, the link falls back to your website in Safari rather than preserving the in-app destination. They do not preserve context through install and do not carry campaign data. The recommended approach on iOS. One limitation appears in in-app browsers.
- Android App Links: The Android equivalent. Your app is verified as the domain owner, and links open directly without a disambiguation dialog. If the app is missing, the link falls back to the web, and like Universal Links, App Links do not preserve install context or carry campaign data. Starting with Android 12, unverified links default to the browser.
- Deferred deep links: These solve the install gap. The user clicks a link, installs through the App Store, and the app retrieves the original link context on first open. They work without the app installed and preserve context through install, but on their own they do not carry campaign data.
- Contextual deep links: Everything deferred deep links do, plus they carry additional data through the install: referral source, campaign ID, promo codes, user segment. They are the only category that works without the app installed, preserves context through install, and carries campaign data. This powers referral programs, personalized onboarding, and campaign attribution.
If you need the original destination or campaign context after install, the last two categories matter most.
Firebase Dynamic Links is gone: what that means for you
Teams that used Firebase Dynamic Links for deferred deep linking need a migration plan. This section shows what changed and what to review in your current flows.
Firebase Dynamic Links has been deprecated, and teams using deferred deep linking should plan migrations to alternatives. The migration guidance recommends native App Links and Universal Links for basic deep linking, and third-party providers for deferred deep linking.
If your app used Firebase Dynamic Links for referral links, share buttons, or email campaigns, confirm whether those flows still work. If another tool handled deep linking behind the scenes, confirm whether migration is complete.
How to set up deep links for your app
Most teams should map destinations before touching verification files or fallbacks. That is because broken path design causes routing problems later. After this section, you will have a practical setup sequence to follow.
Deep link setup follows a sequence: map screens, verify your domain, build fallback pages, and test on real devices. Each step depends on the one before it.
Map your screens first
Clear destination paths come first. Deep links break when the target paths are inconsistent or unclear.
Before configuring anything, list which screens need deep link support. Common categories include product pages for marketing campaigns, order status screens for transactional messages, invite pages for referral programs, and content pages for social sharing.
Use hierarchical, human-readable URL paths. A recommended practice is matching your URL structure. If your site uses yoursite.com/products/sneakers, your deep link should use the same path.
Host verification files
Platform verification proves that your app owns the domain. Without it, native links usually do not open as expected.
Both iOS and Android require a small file on your domain that proves your app owns that domain. iOS needs an apple-app-site-association file. Android needs an assetlinks.json file. Both go in the /.well-known/ directory.
Critical requirements for these files:
- Files must be served over HTTPS
- Content type must be application/json
- Serve the file from the documented location on your domain
- On Android, each subdomain needs its own file
If one of these checks fails, verification usually fails too.
Build real web fallback pages
Fallback pages carry the handoff when the app is missing. A broken web destination turns a valid deep link into a dead end.
Every deep link URL needs an actual web page at that address. When the app is not installed, the OS opens the URL in a browser. A 404 page is a dead end. Your fallback page should show the relevant content plus a prompt to download the app.
Test on real devices across multiple scenarios
Real-device testing shows whether the full handoff works outside the simulator. You need to check installed and not-installed states across the channels people actually use.
Check deep links on physical devices with the app both installed and not installed. Test from email, SMS, and social media platforms. Test from inside social media in-app browsers, where Universal Links will not fire. On Android, wait after installing before testing.
That test pass tells you whether your setup works outside the simulator.
Choosing a deep linking tool
The main decision is simple: decide whether you only need routing for installed users or whether you need context to survive install too. That choice tells you whether native links are enough or whether you need more. After this section, you will be able to match your needs to the right category.
Your choice depends on whether you need deferred deep linking and campaign attribution, or just basic routing for installed users. Start by matching your requirements to the categories below.
When native links are enough
Native links fit apps that only need to open the right screen after install. They handle routing without adding another SDK.
If you do not run paid acquisition campaigns and do not have referral programs, you may not need a third-party tool at all. iOS Universal Links and Android App Links are free, require no SDK, and handle deep linking for already-installed apps. Android added Dynamic App Links for runtime URL matching without releasing a new app version.
When you need a third-party tool
Third-party tools fit cases where install-time context matters. That includes deferred deep linking, referral attribution, and paid campaign tracking across many channels.
For deferred deep linking, referral attribution, or paid campaign tracking across many channels, a mobile measurement partner is often used. Platform-native tools can also provide attribution and event tracking for some use cases.
Free native attribution on iOS
Native attribution may cover some iOS measurement needs without an MMP. The fit depends on how much attribution detail your app needs.
Before paying for an MMP, evaluate AdAttributionKit. Updated at WWDC 2025, it provides privacy-preserving campaign attribution natively on iOS, with expanded capabilities added later.
Privacy and platform changes worth tracking
Deep linking sits inside platform policy, not outside it. Privacy rules and OS changes affect what data your links can pass, collect, and measure. After this section, you will know which changes are worth reviewing in your setup.
What changed on iOS and Android
Recent platform changes affect how links, redirects, and some SDK behavior are reviewed. These changes matter if your setup depends on tracking parameters or local network activity.
Updated App Review Guidelines permit links with parameters, redirects, and intermediate links to landing pages. This removes a previous compliance ambiguity around deep links with campaign tracking parameters.
On Android, apps targeting Android 16 face new network permissions. Review whether any SDK in your setup depends on local network activity.
The expanding legal landscape
Consent matters when your links or SDKs collect personal or behavioral data. That matters most when attribution depends on identifiers or tracking data.
If your deep linking setup collects device identifiers, click data, or behavioral data, build consent flows into your app. This matters even more for younger users and for users in states with active enforcement.
Five use cases where deep linking pays off
Deep linking pays off when a link preserves intent from the tap to the destination. That shows up most clearly in referral flows, re-engagement, attribution, and onboarding. After this section, you will see where the technical setup creates practical value.
A recent platform overview identifies better UX as a core benefit of deep links. Here is where that benefit shows up in practice.
- Referral programs: Generate a unique link per user. When a friend clicks, installs, and opens the app, the SDK credits the referrer.
- Email re-engagement: "You have 3 unread messages" links directly to the inbox. Abandoned cart emails link directly to checkout. For users without the app, the same link routes through the App Store and deep links after install.
- Social sharing loops: When users share content from your app, the share link is a deep link. Recipients with the app land on that content. Recipients without it get routed through install and then to the content. Sharing behavior becomes an acquisition channel.
- Paid campaign attribution: Deep links tie conversions to specific campaigns and pages. On iOS, AdAttributionKit provides a free path to basic attribution without a paid MMP.
- Onboarding context: A user discovers your app through a blog post, taps "Try this in the app," installs, and opens directly into that feature. Time to value shrinks. First impressions improve.
These examples depend on the same thing: the link has to preserve intent from the tap to the destination.
Start with one use case. Map the screens, pick your tool, and test on real devices before launch. If you need a place to start, review the relevant platform docs before you ship your first production link.
