Deep Linking Implementation:The 2026 Guide to Universal Links, App Links, and Life After Firebase Dynamic Links

Deep linking is the mechanism that lets a link — in a text message, an email, a push notification, a QR code, a social post — open your app directly to a specific piece of content, instead of dropping the user on a generic home screen or, worse, a browser tab. Most teams say "we need deep linking" as if it's one feature; it's actually four related but distinct mechanisms, and conflating them is where a lot of production bugs start.

If you're still deciding on a cross-platform framework before any of this becomes relevant, our custom mobile app development guide and cross-platform development guide cover the platform-native versus cross-platform tradeoff more broadly — React Native and Flutter both have workable Universal Links/App Links wrappers, but as with in-app purchases, you'll still end up reading each platform's own documentation for anything past the basic case.

A Universal Link is a normal HTTPS URL — https://yourapp.com/products/42, not a special prefix — that iOS routes to your app instead of Safari when it recognizes the domain as verified for your app. That verification runs through two pieces that both have to agree: an apple-app-site-association (AASA) file your server hosts, and an Associated Domains entitlement (applinks:yourapp.com) your app declares in Xcode.

The AASA file is a JSON document — despite the filename carrying no .json extension — listing which URL paths on your domain your app can handle, keyed to your Team ID and Bundle ID together (the appID field). Apple checks for it at https://yourdomain.com/.well-known/apple-app-site-associationfirst, and falls back to the domain root if that path doesn't resolve — but the fallback only reliably triggers on a clean 404, not on a redirect or an error page that still returns a 200 status. This is the single most common hosting bug behind "my Universal Links stopped working and I don't know why": a CDN or reverse-proxy rule that redirects unmatched paths, quietly breaking Apple's ability to fall back.

One detail that surprises teams migrating from a shortener service: iOS caches its verification of your AASA file rather than checking it on every single link tap, which means a fix you deploy to the file doesn't propagate to already-installed copies of your app instantly. During testing, reinstalling the app — not just re-tapping the link — is the reliable way to force a fresh check.

Handling the link once it does reach your app is its own step, separate from getting the OS to route it there in the first place. On modern iOS, that means implementing scene(_:continue:) (or the older application(_:continue:restorationHandler:) for apps not yet adopting the scene lifecycle) to receive an NSUserActivity of type NSUserActivityTypeBrowsingWeb, parsing its webpageURL, and routing to the matching in-app screen — including the case where the app launches cold directly into that screen, which behaves differently in testing than a link tapped while the app is already running in the background. Teams that only test the warm-launch case routinely ship a cold-launch bug where the app opens to the home screen and silently drops the intended destination.

Android App Links solve the identical problem with a different verification protocol: instead of Apple's AASA format, Android uses the Digital Asset Links standard, hosted as a JSON file at https://yourdomain.com/.well-known/assetlinks.json, paired with an intent filter in your app's manifest carrying android:autoVerify="true".

When your app is installed on Android 6.0 (API 23) or higher, the system inspects every intent filter with a VIEW action, BROWSABLE and DEFAULT categories, and an HTTP or HTTPS scheme, then queries each unique hostname's assetlinks.json to confirm your app is an authorized handler for that domain. Get this wrong — the file missing, wildcarded incorrectly, or hosted behind a redirect — and instead of your app opening automatically, Android falls back to prompting the user to choose an app, or in some cases resolves silently to whichever app was previously selected.

For testing, Android 12 and later expose a manual verification path: adb shell pm verify-app-links --re-verify PACKAGE_NAME followed by adb shell pm get-app-links PACKAGE_NAME to inspect the actual per-domain verification state (values like verified, legacy_failure, or a numeric device-specific error code) rather than inferring it from whether a link happened to open correctly on one test device.

On the client side, receiving the link is handled through onNewIntent() when the app is already running, or by reading the launch Intent's data when the app cold-starts from the link — the same warm-launch-versus-cold-launch split that trips teams up on iOS. A second, Android-specific gotcha: if your manifest declares intent filters for multiple hosts under one activity, every host needs its own matching entry in assetlinks.json, or verification succeeds for some of your domains and silently fails for others — a partial rollout that's easy to miss if your test plan only exercises one hostname.

A custom URL scheme — myapp://profile/42 — is the oldest deep-linking mechanism on both platforms, and it works differently from Universal Links and App Links in one important way: there is no domain-ownership verification step at all. Any app can register any scheme it wants; the OS has no built-in way to guarantee your app is the legitimate handler for myapp://, and if a second app registers the identical scheme, which one actually handles a given link is not fully within your control.

That weakness is exactly why custom schemes should not be the primary mechanism for anything a user receives from outside your app in 2026 — a marketing link, a shared post, a push notification payload — where Universal Links or App Links give you the same functional result with actual domain-level verification behind it. What custom schemes still do correctly: OAuth and third-party SDK redirect callbacks that some providers still implement this way, certain share-extension and cross-app-communication patterns, and any purely internal, never-externally-distributed link your own app generates and consumes without ever leaving the device.

The security implications of continuing to use a custom scheme for something more sensitive than internal navigation — specifically an OAuth callback carrying an authorization token — are covered in detail in the security section below; the short version is that a scheme collision there is not a hypothetical bug, it's a documented account-takeover pattern.

Firebase Dynamic Links (FDL) was, for years, the default answer to "how do I make a short link that opens my app if installed and falls back to a store listing if not." Google announced its deprecation in August 2023, moved the Firebase console to read-only for it in May 2024, and shut it down completely on August 25, 2025. There was no extended grace period after that date and no forwarding service — every link built on FDL's infrastructure, including custom domains routed through it, now returns a plain 404.

The lesson generalizes past this one service: a "free" infrastructure dependency from a major platform vendor is not exempt from being discontinued on that vendor's own schedule, and deep linking specifically has a history of this — Google's separate discontinuation of Play Instant Apps, covered later in this guide, is a second example inside the same eighteen-month window. Native Universal Links and Android App Links don't carry this specific risk in the same way, since they're core platform capabilities rather than a discrete product Google or Apple could sunset independently — but any third-party vendor layered on top of them is still a vendor, with its own continuity risk.

Deferred deep linking solves a specific gap Universal Links and App Links don't cover on their own: routing a brand-new user, who didn't have your app installed at the moment they tapped a link, to the specific content that link pointed to once they finish installing — rather than a generic first-launch home screen. Before 2021, this was commonly solved by passing the device's advertising identifier (IDFA) through the click-to-install flow and matching it server-side once the app opened for the first time — a deterministic, reliable match.

Apple's App Tracking Transparency (ATT) framework made IDFA access opt-in, and the large majority of users decline the prompt — which means deferred deep linking on iOS today mostly runs on probabilistic matching instead: correlating signals like click timestamp proximity, IP address, and device/OS characteristics between the original tap and the subsequent app open, with no single identifier guaranteeing correctness the way IDFA did.

On the number every vendor wants to give you: we searched specifically for an independently audited deferred-deep-link match-rate benchmark and found none. What circulates instead is self-reported vendor marketing content with no disclosed methodology, no stated traffic conditions, and no way to know whether a given percentage reflects a clean single-device-per-household scenario or the much noisier reality of shared Wi-Fi, VPNs, and iCloud Private Relay degrading IP-based signal quality. We refuse to print any of those numbers here as fact — measure your own match rate against your own install funnel instead.

Since iOS 17, Safari strips known tracking parameters from links automatically in Private Browsing — and can be enabled for regular browsing — using Apple's own maintained list of tracking-parameter patterns. The same stripping applies to links opened from Messages and Mail regardless of that setting, which matters directly for deep linking because push notifications, SMS campaigns and email are exactly the channels most deep links travel through.

The mechanism leaves your app's actual destination path intact — a link still opens the right screen — but it can silently remove the click-ID or campaign-tracking parameter your attribution vendor was relying on to tie that specific tap to a specific ad or campaign, before your server or SDK ever receives it. Combined with the IDFA restrictions covered above, this is a second, independent reason deferred-deep-link and attribution matching has shifted toward less parameter-dependent, more probabilistic methods over the past few years — not a preference, a forced adaptation to two separate platform privacy changes landing within a few years of each other.

On the ad-attribution side specifically, Apple's own SKAdNetwork remains operational at version 4.0 (released October 2022), while AdAttributionKit — Apple's newer, longer-term privacy-preserving successor framework — received significant updates at WWDC 2025 and is the direction Apple is steering new attribution integrations toward, without an announced hard cutover date for SKAdNetwork as of when we checked. If your deep-linking and attribution stack touches paid acquisition at all, that migration path is worth scoping alongside the deep-linking work itself, not as a separate project six months later.

Deep link and intent handling maps directly onto categories in OWASP's Mobile Application Security Verification Standard (MASVS) — specifically the controls covering insecure authentication flows and security decisions made on untrusted input. The pattern underneath most real incidents is simple to state and easy to miss in review: a deep link's URL and parameters are input a user (or an attacker) controls, not a trusted internal signal, and code that treats them otherwise is the actual vulnerability.

• Scheme hijacking: Two apps register the identical custom URL scheme; the OS has no ownership check, so which app actually receives a given link isn't fully guaranteed by your app alone.
• Unverified Universal Link / App Link fallback: A missing, wildcarded, or redirect-hosted AASA/assetlinks.json file causes verification to fail silently, and the platform falls back to less secure resolution — a disambiguation dialog on Android, or an ordinary (unverified) web link on iOS.
• OAuth or magic-link callback hijacking: An authorization code or token returns through a deep link that a sibling app can also claim — via a scheme collision or a failed App Links verification — handing that token to the wrong app entirely.
• Unvalidated deep-link parameters used for authorization: A user ID, discount code, or feature flag embedded in a deep link is trusted directly instead of re-validated server-side, letting a forwarded or forged link grant access it shouldn't.

The OAuth case is worth one more layer of detail because it's where deep-link security failures turn into account takeovers rather than annoyances. The standard mitigation, independent of which link mechanism carries the callback, is to generate a random state parameter before starting the authorization flow, store it locally, and reject any callback whose statedoesn't match — that alone defeats a large share of redirect-hijacking attempts, since an attacker's app can receive the callback but won't have the value your app generated. Exchanging an authorization code for a token server-side, rather than trusting a token handed directly in the callback URL, closes the remaining gap: even if a malicious app briefly intercepts the callback, a code alone is not usable without your server's client secret to complete the exchange.

If your broader mobile security posture hasn't had a structured review recently, our mobile app security guide covers the wider OWASP Mobile Top 10 surface this deep-linking-specific section is one slice of.

The order matters because each step depends on the one before it, or fails invisibly without it — the same pattern that governs push notification and in-app-purchase infrastructure applies here, with deep linking's specific failure modes swapped in.

A note on ownership: association-file hosting, domain verification state, and any legacy shortener migration all need a named owner and a recurring check, not a one-time task closed at launch. A deep-linking setup that worked correctly at launch degrades quietly as infrastructure shifts underneath it — a CDN configuration change that breaks the AASA fallback, a marketing tool that reintroduces a dead shortener domain into a new campaign template — and by the time click-through data shows a drop, the underlying cause has often been live for weeks.

This is not a ranked top list, for the same reason a purchase-infrastructure vendor comparison isn't one: native Universal Links and App Links are mandatory platform layers every vendor below sits on top of, so the useful question is what a given vendor actually replaces for you, not which one scores highest on a benchmark nobody can independently verify.

Building this yourself is defensible when your primary need is straightforward content routing — a notification opens the right product page, a shared link opens the right post — without heavy cross-channel ad-attribution requirements. A vendor earns its fee once ad-spend attribution, a maintained and Apple-compliant deferred-matching pipeline, or cross-campaign link analytics become genuinely necessary; none of them changes what Apple's or Google's platform rules allow, or removes your own obligation to validate deep link parameters server-side rather than trusting them at face value.

The following is an illustrative worked scenario, not a real client engagement or a reported outcome — the arithmetic uses realistic, stated assumptions to make the cost of a silent deep-linking failure concrete.

Consider a subscription app sending 200,000 push notifications a month that each deep-link to a specific piece of content — a new episode, a personalized recommendation, a renewal offer. Industry-typical push open rates vary widely by app category and audience, so rather than assume a specific rate, assume this app measures its own baseline at 8% opens, or 16,000 taps a month, and that historically 90% of those taps land the user on the correct in-app screen (some fraction always fails due to edge cases like a cold-start race condition).

The honest reading of that table is not that a broken deep link is a catastrophe on its own — most of those 3,600 users still open the app, just to the wrong screen, and many will navigate manually. The point is that this class of failure is silent by design: nothing throws an error, no crash report fires, and the only visible signal is a click-through or conversion metric drifting down for reasons that look, from a dashboard, indistinguishable from normal noise. The discipline this scenario is meant to illustrate is testing the actual link on a real device after every hosting or CDN change that touches your domain's root or .well-known path — not just reviewing the configuration file by eye.

If you're evaluating proposals for a broader app rebuild that happens to include deep linking as one piece, our mobile app RFP template guide covers how to write scope language specific enough that competing agencies' "deep linking supported" claims are actually comparable, rather than each vendor claiming the feature at very different levels of rigor.

One scoping note specific to this domain: the discovery phase for deep-linking work should always include a live-link audit — actually tapping a representative sample of links from your current marketing emails, push templates and any printed QR codes on a real device with the app installed, rather than reviewing configuration files alone. This is the fastest way to surface a dead Firebase Dynamic Links domain, a redirect quietly breaking your AASA fallback, or an assetlinks.json mismatch nobody has noticed because nobody has tested the actual link path recently.

None of this replaces your own testing against your specific domain, app configuration and traffic mix — deep linking touches hosting, native app entitlements, and (if you use one) a third-party vendor's own infrastructure simultaneously, and a guide like this one can only describe the current state of three platforms' rules as of the date it was checked, not guarantee they haven't shifted by the time you read it.