skip to content

In a React Native app, what is a deferred deep link, and why can't Linking.getInitialURL() deliver one after a fresh install?

level: middleimportance: nice to knowfreq 25%

answer

  1. the link was tapped before install
  2. the store drops the URL
  3. first launch sees null
  4. something must remember the link
  5. match after install, then route

basics

~20 s

A deferred deep link is one tapped before the app was installed, whose destination should still open after install. The store install breaks the chain, so the first launch has no launch URL and getInitialURL() resolves null.

solid answer

~50 s

A **deferred deep link** is a link a user taps before the app is installed, for example an invite link, where the goal is to land them on the right screen after they install from the store and open the app. `Linking.getInitialURL()` cannot provide it because the first launch is started from the home screen, not by the link: the OS has no launch URL to pass, so the call resolves to `null`. Something outside `Linking` must remember the link across the install and hand it back: the website can record the intent server-side and the app can claim it after sign-up or sign-in, Android can pass an install referrer string through the Play Store, or a dedicated attribution SDK can match the install. Once the app recovers the URL, it should go through the same validation and routing path as any other link.

go deeper

for a junior

Recall that a deferred deep link was tapped before install, and that the first launch after install has no launch URL.

for a middle

Explain why the store install breaks the link chain and name the ways to carry the intent across: account-based, install referrer, attribution SDK, clipboard.

for a senior

Choose an approach by reliability and privacy cost, and route the recovered link through the same pending-link and validation path as cold starts.

for a principal

Decide whether deferred linking justifies a third-party attribution dependency or whether account-bound invites cover the product need.

## Three kinds of deep link by timing | Kind | App state when tapped | How the URL reaches JavaScript | |---|---|---| | **Warm** | installed and running | `Linking` `'url'` event | | **Cold** | installed, not running | `Linking.getInitialURL()` | | **Deferred** | **not installed** | nothing built into React Native | The first two are ordinary deep links. The third is a product requirement layered on top: "if someone without the app taps an invite, install should not lose where they were going". ## Why the chain breaks Follow the steps of a user tapping `https://app.example.com/invite/team-42` without the app: 1. The OS finds no app for the link, so it opens the website (or a custom scheme simply fails). 2. The website sends the user to the App Store or Play Store. 3. The user installs the app. 4. The user opens the app from the home screen or the store's Open button. At step 4 the app was launched by the launcher, not by the link. The OS therefore has no URL in the launch options or the launching intent, and `Linking.getInitialURL()` correctly resolves to `null`. React Native is not dropping anything; there was never a link to deliver. ## Ways to bridge the gap All of them store the intent somewhere that survives the install, then give it back to the app on first run: - **Account-based (deterministic).** The web page records "this visitor wants to join team 42", for example against an email address they enter, or the invite is already tied to an invited email. After the user signs up or signs in, the app asks the server for pending invites. This is exact and needs no device matching, but only works after authentication. - **Android install referrer.** A Play Store link can carry a referrer string, which the installed app can read through Google Play's install-referrer API and turn back into a route. It is Android-only and needs a native library. - **Attribution services.** Third-party SDKs match the click to the install and return the original link on first launch. They add a dependency, a privacy review and, often, a data-sharing disclosure. - **Clipboard handoff.** A web page copies a token that the app reads on first launch. On current iOS versions reading the clipboard shows the user a system paste prompt, so this is intrusive and unreliable. Probabilistic matching of device characteristics across the web and the app is also used in the industry, but it is fragile and runs into platform privacy rules, so it should not be the default design. ## What the React Native app does once it has the link Treat a recovered deferred link exactly like a cold-start link: 1. Store it as a **pending link** until onboarding or sign-in is finished. 2. Validate it with the same allowlist and parsing code as other links. 3. Route to the destination, then clear it so it is applied once. Keeping one code path for all three timings avoids a second, less-tested router that only runs on first install. ## Testing a deferred link Deferred links are hard to test because they span the website, the store and a first launch: - test the **fresh-install** path by deleting the app, tapping the link and installing a build, not by relaunching an installed app; - confirm that `getInitialURL()` is `null` on that first launch, so the recovery path is really the one being exercised; - confirm that the recovered link survives onboarding and sign-in, the steps most likely to drop it. ## Interview framing Interviewers usually ask this to see whether the candidate: - knows that `getInitialURL()` returning `null` on first launch is correct behaviour, not a bug; - can name the realistic options and their costs without depending on a single vendor; - routes the recovered link through the same validation as any other link. A strong answer ends with the simplest reliable option for the product, often the account-based one for invites and referrals, and reserves attribution services for marketing campaigns where sign-in is not the first step.

  • For a team-invite feature, which deferred-link approach is usually simplest and most reliable?
    Tie the invite to the invited email address on the server. After install, the user signs up or signs in with that email, and the app asks the server for pending invites and routes to the team. No device matching, clipboard access or third-party SDK is needed, and it works identically on iOS and Android.
  • Once a React Native app recovers a deferred link, how should it be handled?
    Exactly like a cold-start link: store it as pending until onboarding or sign-in completes, run it through the same URL validation and route allowlist, navigate, and clear it so it applies once. A separate first-install router tends to skip validation and rot because it runs rarely.

saying these in an interview costs you the question

  • getInitialURL() returning null on first launch after install is a React Native bug
  • The App Store forwards the original link to the app's first launch
  • A universal link alone makes deferred deep linking work
  • Reading the clipboard on iOS is a silent, reliable handoff