Landing Users on the Right Screen Right After Install — Deferred Deep Links for Rork Apps

Recover the destination on first launch, app-side

The app attempts recovery exactly once, on first launch. It checks the clipboard first, and if that whiffs, it queries the server's fingerprint matcher.

// resolveDeferredLink.ts
import * as Clipboard from "expo-clipboard";
import { router } from "expo-router";
 
const FIRST_RUN_KEY = "dl_resolved_v1";
 
export async function resolveDeferredLink(storage: Storage) {
  // Run only on first launch (so later launches don't absorb someone else's link)
  if (await storage.getItem(FIRST_RUN_KEY)) return;
  await storage.setItem(FIRST_RUN_KEY, "1");
 
  // Path 2: clipboard
  const clip = await Clipboard.getStringAsync();
  const m = clip.match(/^rork-dl:(\/\S+)$/);
  if (m) {
    await Clipboard.setStringAsync(""); // clear the copy once it's used
    router.replace(m[1]);
    return;
  }
 
  // Path 3: server fingerprint matching
  const target = await matchFingerprint();
  if (target) router.replace(target);
}
 
async function matchFingerprint(): Promise<string | null> {
  const res = await fetch("https://api.example.com/dl/match", {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify(currentFingerprint()),
  });
  const { target, confidence } = await res.json();
  // Don't accept low-confidence matches (a wrong landing hurts the experience)
  return confidence >= 0.7 ? target : null;
}

Using router.replace here rather than push is subtle but important. Instead of stacking the destination on top of the home screen, you replace the initial landing itself, which keeps the back-button behavior natural. I first built it with push and created a glitch where backing out of the destination flashed an empty home screen for an instant.

The threshold and window that prevent wrong matches

Path-3 fingerprint matching is probabilistic, so there's always a risk of "absorbing someone else's link by mistake." The design that suppresses this is what determines quality. The three rules I run with:

• Keep the matching window short. Records older than 1 hour from click to first launch are dropped from matching. The median time from ad click to install completion was within a few minutes for my apps, so an hour was plenty.
• Produce a confidence score from the number of matching features and reject anything under 0.7. Weight platform, language, timezone, and screen resolution agreement, and throw away merely vaguely-similar candidates.
• Mark a click record as consumed the instant it's matched. Even if multiple launches hit the same fingerprint, only the first recovers; the rest fall back to a normal home landing.

A wrong landing breeds the distrust of "you took me somewhere I never asked for," so when in doubt, don't recover. I initially set the confidence threshold at 0.5, took one complaint about landing on an unrelated screen, and raised it to 0.7. With probabilistic methods, designing as if the cost of a false positive is high turns out to be the shortcut.

Where to draw the build-it-yourself line

Honestly, once you're running ads at scale and need rigorous attribution, a dedicated SDK is easier to operate. A homegrown implementation means keeping up with OS changes to clipboard APIs and degrading fingerprint precision yourself.

Even so, in the early indie phase — up to maybe tens of thousands of installs a month — this lightweight design covers the minimum: landing campaign visitors on the right screen. Keep a setup that stashes no personal data externally and carries no fixed cost as your first tier. Then consider an SDK once your scale comes into focus. That order suited me; I hope it gives anyone weighing the same decision something to go on.