Deferred deep linking, explained

scope

What "deferred deep linking" means as a precise engineering term, how it works on Android, why it broke on iOS, and what your options are now. This guide assumes familiarity with Universal Links and App Links — if not, start at /guides/universal-link-vs-deep-link-vs-app-link.

Cluster C hub: /guides/firebase-dynamic-links-replacement.

the definition

A deferred deep link is a URL whose destination is preserved across a cold app install. User taps https://yourapp.com/product/123. App is not installed. User goes to the App Store / Play Store, installs the app, opens it. The app launches at product/123 instead of the default home screen.

Three components must work together:

1. The original link must be capturable before the install.
2. State must persist across the install (which involves leaving your domain entirely to visit the platform store).
3. On first launch, the app must read the persisted state and route to the original destination.

The state-persistence step is the hard one. The OS-level handoff from "user tapped a link on the web" to "user just opened the app for the first time" does not natively carry payload data on iOS. Android has a clean mechanism. iOS does not.

why this is different from a regular deep link

A regular Universal Link or App Link routes a URL to an installed app. If the app isn't installed, the URL falls back to web. The "deferred" part is the additional requirement: the user installs the app from the store mid-flow and then expects the original destination.

The deferred case is where Firebase Dynamic Links earned its keep, and where the FDL shutdown left the largest gap.

Android — the clean mechanism

Google ships Play Install Referrer, a clean platform-provided way to pass install-time state.

The flow:

1. User taps a link that opens the Play Store with a referrer query parameter: https://play.google.com/store/apps/details?id=com.yourapp&referrer=utm_source%3Dyourdomain%26slug%3Dproduct-123.
2. The Play Store records the referrer string with the install event.
3. App is installed.
4. On first launch, the app initializes the InstallReferrerClient and reads the referrer.

class MainActivity : AppCompatActivity() {
    private lateinit var referrerClient: InstallReferrerClient

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        referrerClient = InstallReferrerClient.newBuilder(this).build()
        referrerClient.startConnection(object : InstallReferrerStateListener {
            override fun onInstallReferrerSetupFinished(responseCode: Int) {
                when (responseCode) {
                    InstallReferrerClient.InstallReferrerResponse.OK -> {
                        val response = referrerClient.installReferrer
                        val referrerUrl = response.installReferrer
                        // referrerUrl is "utm_source=yourdomain&slug=product-123"
                        routeFromReferrer(referrerUrl)
                    }
                }
                referrerClient.endConnection()
            }
            override fun onInstallReferrerServiceDisconnected() {}
        })
    }
}

The referrer string is preserved by the Play Store across the install. The mechanism is reliable, free, and platform-supported.

Limitations on Android:

• Only works for installs through Play Store. Sideloaded installs don't carry the referrer.
• The referrer is readable for a window after install (typically several days), then expires.
• Pre-install browsing context (e.g., the original URL the user tapped on the web) must be encoded into the referrer string at the redirect step. Your server controls this.

For the assetlinks.json / App Link setup that makes the post-install routing work: /guides/android-app-links-setup.

iOS — the broken mechanism

iOS has no equivalent to Play Install Referrer. The mechanisms that historically simulated one are:

1. Fingerprint matching. Before App Tracking Transparency (ATT), SDKs would record device characteristics (IP, User-Agent, screen size, language, timezone) at link-tap, and again at first app launch, and match the two. Match rate was ~60–80% under ideal conditions.

2. Pasteboard-based handoff. A server-side redirect copied the destination URL into the device pasteboard before sending to the App Store. The app, on first launch, read the pasteboard.

3. IDFA (Identifier for Advertisers). Used by attribution SDKs to match a click event to an install event.

All three are broken or restricted in 2025:

• Fingerprint matching is unreliable post-IPv6 widespread deployment (Apple Private Relay shuffles IPs) and is technically against Apple's App Tracking Transparency guidelines without user consent.
• Pasteboard access triggers a system-level "X pasted from Safari" notification banner since iOS 14, and on iOS 16+ requires user consent for non-foreground pasteboard reads. Apps using this mechanism are surfaced to the user as suspicious.
• IDFA is opt-in only since iOS 14.5 and effectively unavailable in practice (industry opt-in rates ~25%).

The replacement is SKAdNetwork, Apple's privacy-preserving attribution framework — but SKAN provides aggregate conversion postbacks, not per-user destination routing. SKAN tells you "10 users installed from this campaign." It cannot tell your app "this specific user tapped product 123."

In short: deferred deep linking on iOS in 2026 is a degraded product. No technically clean mechanism exists. Vendors who claim otherwise are using best-effort techniques that operate at the edge of Apple's guidelines.

what the SaaS layer actually does

Branch, AppsFlyer OneLink, and Adjust all implement deferred deep linking. Under the hood, each does:

On Android: uses Play Install Referrer (per above). Mechanism is clean; the SaaS adds analytics, link-builder UX, and cross-platform link generation.

On iOS: uses a combination of:

• Fingerprint matching against probabilistic IP/UA cohorts (lossy)
• Optional pasteboard handoff (user-visible, ATT-gated)
• SKAdNetwork postbacks for aggregate attribution (per-user routing not possible)

The accuracy claims you see in vendor marketing materials cover Android specifically, where the mechanism is clean, then average that with iOS, where it's a best-effort approximation. Always ask vendors for the iOS-only match rate, not the blended number.

Alternatives pages: /guides/branch-io-alternative, /guides/appsflyer-onelink-alternative, /guides/adjust-deep-links-alternative.

design implications

If you're building an install funnel that depends on deferred deep linking, the following design choices follow from the platform realities:

1. Don't make first-launch routing critical to the conversion event. Build your onboarding to handle the case where the original destination is not recoverable. The Android-only path is reliable; the iOS path is best-effort. Plan for the worst case.

2. Use the URL itself as a fallback. Display the original link, or a sign-in prompt that re-establishes the destination context. iOS users can re-tap a link from email after install, which works because the app is now installed and the Universal Link routes directly.

3. Don't bake high-value flows behind a deferred routing assumption. If 50% of your iOS users land at the home screen instead of the intended destination on first launch, your funnel breaks for half your iOS installs.

4. Track the iOS-vs-Android match rate explicitly. Don't accept blended numbers from your attribution vendor; the platform-specific numbers tell the story.

the alternative: don't defer

For many use cases, deferred deep linking is solving a problem that no longer needs solving. Consider:

• Modern apps frequently surface a "Continue with email" or "Continue with Apple" sign-in on first launch. Once the user authenticates, you can route them based on their server-side state, not link-time state.
• Magic-link sign-in (a URL emailed after install) re-establishes routing via a Universal Link from the user's mail app. The mail-app surface respects Universal Links cleanly.
• For ecommerce, post-install routing matters less than the first session's product discovery. Most users browse, they don't land on a specific product.

If your conversion model doesn't require the original-link destination at install time, the simplest answer is to drop the deferred requirement and design around a clean "first launch, then sign-in, then route" flow.

what about web-only flows

The deferred-deep-linking problem doesn't apply to non-app flows. If your "link" routes to a bio page, a checkout URL, a music release, or a creator funnel, none of the iOS-attribution restrictions matter — the user just opens the link in a browser.

The relevant failure on the web side is in-app browser cookie isolation: links that work in the system browser fail in social-app webviews. Mechanism breakdown: /guides/in-app-browser-cookies-explained. Consumer-side thesis: /guides/in-app-browser-logged-out.

This is the use case linkboo serves. No SDK, no install attribution, no mobile app integration. The non-app deep-linking problem is bounded and tractable.

related dev reading

• Cluster C hub: /guides/firebase-dynamic-links-replacement
• Migration playbook: /guides/firebase-dynamic-links-migration
• Android setup: /guides/android-app-links-setup
• iOS setup: /guides/ios-universal-links-setup
• Intent URL handoff: /guides/intent-url-android
• SaaS alternatives: /guides/branch-io-alternative, /guides/appsflyer-onelink-alternative
• Bridge to consumer-side: /guides/in-app-browser-logged-out

If the non-app side of your linking infrastructure is part of your stack, the no-SDK contract is at link.boo/api.

references

• Apple App Tracking Transparency framework documentation
• Apple SKAdNetwork documentation
• Google Play Install Referrer Library documentation
• Firebase Dynamic Links shutdown FAQ
• Apple Pasteboard privacy disclosures, iOS 14 / iOS 16