Referral links after Dynamic Links: the half that does not migrate

What is a referral link actually doing?

Strip a working invite flow down and there are four separate jobs in it. Only the first is routing.

1. Route the tap to the right store for the device.
2. Remember which invite it was while the visitor leaves the browser, goes to the store, installs, and opens the app — a gap of anywhere from thirty seconds to several days.
3. Recognise, at first launch, that this new user is the one who tapped that invite.
4. Credit the referrer, and land the new user somewhere that reflects the invite.

Dynamic Links did all four, which is why it felt like one feature and why replacing it feels harder than it should. Jobs 2 and 3 are deferred deep linking. They happen across an install boundary, they require code inside your app, and every product that does them is doing install attribution — because carrying a payload across an install and identifying which install it was are the same problem wearing two names.

That is the split. Job 1 is a link. Jobs 2 and 3 are a platform. If you migrate the first and assume the rest follows, the invite flow silently stops crediting anyone, and the failure shows up as a support ticket weeks later rather than as an error in a log.

Why did deferred deep linking get harder on iOS?

The mechanism many implementations leaned on for the recognition step was probabilistic matching — comparing signals from the click against signals from the first launch and deciding they were probably the same device. Apple’s position on the strong version of that is not conditional: fingerprinting is not permitted, regardless of whether the user granted permission, and enforcement tightened through 2024 with required-reason API declarations gating access to the device signals it depended on.

Two things follow, and they are frequently collapsed into one.

Deferred deep linking is not itself prohibited. Deep linking implemented to improve the user’s experience is permitted. What is prohibited is fingerprinting, and transmitting identifiers or device metadata for attribution purposes requires App Tracking Transparency consent.

But the compliant version is weaker. Matching within the rules uses limited signals in a short time window. Accuracy falls sharply when many users share an IP address — an office, a campus, a mobile carrier’s NAT — and disappears entirely for anyone on iCloud Private Relay. So the honest description of a compliant iOS referral flow today is that it works most of the time, fails silently for a minority you cannot enumerate, and degrades further the longer the gap between tap and launch.

Android is in a better position here, because the Play Install Referrer API is deterministic rather than probabilistic: the referrer string you attached to the click is handed back to your app at first launch. The two ways that referrer gets read are worth understanding, because the per-install one is exactly this job and it is the one that needs code.

What are the real options?

Run a measurement platform. This is the direct replacement, and if referrals are load-bearing for growth it is the correct answer. Google’s own deprecation list is mostly these products, and their migration guides address this specific flow. You accept an SDK, a plan sized to install volume, and usually a sales conversation. What you get is jobs 2 and 3, maintained by people whose job it is to keep them working as the platforms change.

Build the Android half and accept the iOS gap. The Install Referrer API is public and deterministic, so Android referrals can be built directly without a platform. iOS has no counterpart — there is no install referrer on iOS at all — so this path means Android referrals work and iOS referrals do not, which is a defensible choice only if your growth is Android-shaped and you say so out loud in the plan.

Change the flow so job 3 disappears. The most underrated option. The new user installs through an ordinary link and then enters the code — typed, or pasted from a clipboard they copied before leaving. It costs one step in onboarding, and in exchange there is no matching, no attribution window, no SDK, no platform difference and nothing to break when a store changes its rules. Plenty of large referral programmes work exactly this way, and they do it because the deterministic version is the one that still works in five years.

The third option is worth pricing properly before dismissing it. The cost is a measurable drop-off at one onboarding step. The alternative is a dependency on cross-install matching that is already degrading on one platform and is outside your control on both.

What about the rest of the migration?

Everything that is not an invite — bio links, ad destinations, QR codes, README badges, store listing URLs, email footers — is job 1 only. Those rebuild in an afternoon and do not need any of the above. Finding all of them is the part people underestimate, particularly if your team ever configured a custom link domain, because the shutdown took those too and they do not look like Firebase links.

If you end up running a measurement platform for the referral flow, the two products are not alternatives and do not need to be chosen between: an AppIn link can point at the platform’s link, so the visitor arrives at it from a real browser rather than from inside an in-app browser that may drop them on a blank page first. That is the shape we already recommend for OneLink, and it applies to any measurement link on any platform.

We do not do deferred deep linking or install attribution, and that is a boundary rather than a roadmap item. Both need an SDK inside your app, which is the thing this kind of product exists to avoid. The routing half is what we replace — and for most of the links in your inventory, the routing half is all there ever was.

Questions

Can I replace a Firebase Dynamic Links referral flow with a link shortener?

No. A referral link has to carry a payload across the install so that first launch knows which invite it belongs to. That is deferred deep linking, it requires code inside your app, and no link-only product provides it.

Why is deferred deep linking harder on iOS now?

Fingerprinting is prohibited by Apple regardless of user permission, so the probabilistic device matching that some implementations relied on is not an option. Compliant matching uses limited signals in a short window, and accuracy falls sharply on shared IP addresses and disappears under iCloud Private Relay.

Is deferred deep linking itself against Apple's rules?

No. Deep linking implemented to improve the user experience is permitted. What is prohibited is fingerprinting, and transmitting identifiers or metadata for attribution requires App Tracking Transparency consent.

What is the simplest referral flow that does not need an SDK?

Ask for the code. The new user installs through an ordinary link and enters or pastes a referral code on first launch. It costs a step and works on both platforms with no matching, no SDK and no attribution window.

Does AppIn do deferred deep linking?

No, and it is a deliberate boundary rather than a gap. AppIn replaces the routing half of what Dynamic Links did. If you need the other half, run a measurement platform and put an AppIn link in front of its link.