Skip to content
DL2App

Blog

What is deferred deep linking? How it works on Android and iOS

Deferred deep linking sends someone who installs your app from a link to the screen that link pointed to, on first launch. How it works on Android and iOS, how it differs from a normal deep link, and its limits.

· DL2App · 6 min read

Deferred deep linking is a link that still takes someone to the right screen in your app when they don't have the app yet. They tap the link, install the app from the store, open it, and land on the product, invite or article the link pointed to, instead of the home screen.

It is called deferred because the deep link can't be followed at the moment of the tap (there is no app to open), so it is held back and delivered on the app's first launch.

An example

Priya sends Sam a referral link to a food delivery app: https://go.foodapp.com/invite/PRIYA20.

  • Sam has the app: the link opens it on the invite screen. That's an ordinary deep link.
  • Sam doesn't have the app: the link opens the App Store or Google Play. Sam installs and opens the app.
    • Without deferred deep linking, the app opens on its welcome screen. The invite code is gone, and so is Priya's referral credit.
    • With deferred deep linking, the app opens on the invite screen with PRIYA20 filled in.

Deep link, deferred deep link, and the rest

Term What it does when the app is installed When it isn't
Custom scheme, like foodapp://invite Opens the app Error or nothing
Universal Link / App Link, like go.foodapp.com/invite Opens the app on that screen Opens the website
Store link Opens the store page Opens the store page
Deferred deep link Opens the app on that screen Store, then that screen on first launch

Universal Links (iOS) and App Links (Android) are built into the phones and are free. Neither carries anything through an install. That part always needs something extra: a server that sees the tap, and code in the app that asks for it on first launch.

How it works

Every deferred deep linking setup has the same three steps:

  1. The tap is recorded. The link goes to a server first. If the app isn't installed, the server notes the tap (which link, when, and a few details about the device) and sends the person to the store.
  2. The app is installed and opened. On first launch, code in the app asks the server: "did this install come from a tap?"
  3. The link is delivered. If the server can tie the install to a tap, it returns the link, and the app routes to that screen. This should happen once per install.

The hard part is step 3: connecting an install to a tap. Android and iOS do it differently.

Deferred deep linking on Android

Android has an exact answer. A Google Play link can carry a referrer parameter:

https://play.google.com/store/apps/details?id=com.foodapp&referrer=tap_id%3Dabc123

Google Play keeps that string through the install, and the app reads it on first launch with the Play Install Referrer API. The app sends tap_id=abc123 to the server and gets the original link back. No guessing.

The limit: it only works for installs from Google Play, not for sideloaded apps or other app stores.

Deferred deep linking on iOS

The App Store passes nothing through an install, and Apple has no equivalent of the install referrer. So iOS uses one of two methods:

  • Matching. The server compares the app's first request with recent taps: network address, iOS version, screen size, language, time zone, and how long ago the tap was. If one tap clearly fits, that's the link. It's invisible to the person, but it's a probability. It works best when the tap and the first launch happen on the same network, and it gets worse with VPNs, iCloud Private Relay, switching between Wi-Fi and mobile data, or many people tapping the same link from one office.
  • Clipboard hand-off. The page before the App Store copies a token, and the app reads it on first launch. It's exact, but since iOS 16 reading the clipboard shows a paste prompt, so most apps use a paste button the person taps.

A good matcher would rather return no match than the wrong one. Opening someone else's invite is worse than opening the home screen.

Apple's rules say apps may not combine device details to identify a device for tracking. Matching that's used only to deliver the link someone just tapped, kept briefly and never used for ads, is how link services read those rules, but it's worth knowing the rule exists. If you'd rather not match at all on iOS, use the clipboard hand-off only.

What it's used for

  • Referrals and invites: the code survives the install, so the person who invited gets credit.
  • Ads and social posts: someone taps an ad for a product and lands on that product after installing, not on the home screen.
  • Sharing: a shared playlist, listing or article opens for the person who installed the app to see it.
  • Onboarding: pre-fill a promo code, pick the right language or skip steps based on the campaign.
  • Measuring campaigns: each install is tied to the link that brought it.

How to add it

You can build it or use a service.

Building it yourself means a link server that records taps and redirects to the right store, the apple-app-site-association and assetlinks.json files so the same links open the app when it's installed, the Install Referrer on Android, matching or a clipboard hand-off on iOS, and first-launch handling in the app. It's a few weeks of work, most of it on iOS, and the server has to stay up as long as your links are out there.

A deep link service runs the server and gives you an SDK for the app. Firebase Dynamic Links did this for free until Google shut it down on 25 August 2025; our Firebase Dynamic Links page covers what replaced it. DL2App includes deferred deep linking on every plan, including the free one: exact on Android through the Install Referrer, and on iOS a short-window match with an optional clipboard hand-off. The deferred deep linking docs list exactly how each install is matched and the limits. For React Native and Expo, there's a step-by-step setup.

How to test it

  • Delete the app first. A deferred link is only delivered on an install's first launch.
  • Android: install from Google Play (an internal testing track works). A build from Android Studio has no referrer.
  • iOS: tap the link in Safari or Messages, install (TestFlight works), and open the app on the same network.
  • Try the shapes that fail: a link tapped inside Instagram, a tap on Wi-Fi then an install on mobile data, a restart during onboarding.
  • If a link doesn't open the app when it is installed, that's a Universal Link or App Link problem, not a deferred one: see Universal Links not opening your app and Android App Links not opening your app.

Questions people ask

What is the difference between deep linking and deferred deep linking? A deep link opens a specific screen in an app that's already installed. A deferred deep link does the same for someone who doesn't have the app yet: it sends them to the store and opens that screen on the app's first launch.

Does deferred deep linking work on iOS? Yes, but not exactly the way it does on Android. iOS has no install referrer, so the install is either matched to a recent tap (invisible, but a probability) or handed over through the clipboard (exact, but the person taps a paste button).

Is deferred deep linking exact on Android? For installs from Google Play, yes. The Play Install Referrer carries the tap's ID through the install.

Can I do deferred deep linking without an SDK? On Android you can read the Install Referrer yourself with Google's library. On iOS you need your own matching server or a clipboard hand-off. Either way, something has to record the tap before the store opens.

Is deferred deep linking free? The phone features it relies on are free. The server is the cost: build and run it yourself, or use a service. DL2App includes it on its free plan.

All posts

Start with one link

The free plan has no time limit and needs no card. Create a project, add your app, and send yourself the link.