Make Deep Links and Attribution Survive the App Store Round Trip

You run a campaign, someone taps your link on their phone, and they do not have the app yet. They land in the App Store, install, open the app, and arrive at a generic home screen with no memory of why they came. The product they wanted, the discount they clicked, the shared invite that brought them, all of it evaporated in the trip through the store. That gap between intent and arrival is where mobile growth quietly leaks, and closing it is a solved engineering problem that most teams ship half-finished.

The fix has two parts that people conflate. Deep linking gets an existing-app user straight to the right screen. Deferred deep linking remembers that destination across an install, so a brand-new user who tapped your link lands on the same specific screen after they download and open the app for the first time. That first screen is also your one shot to get a new user to their first win before they think of leaving, which is exactly why dropping the intended destination is so costly. Attribution is the third leg: knowing which click led to which install, so you can tell what actually drove growth. Get all three wired correctly and a tapped link survives the round trip through the store. Get one wrong and users fall into the void.

The platform plumbing you cannot skip

Both platforms require a verified association between your domain and your app. This is not optional decoration; it is the entire trust mechanism, and when it is misconfigured the links fail silently, which is the worst failure mode because nothing errors and everything just quietly does not work.

On iOS, Universal Links are backed by an apple-app-site-association (AASA) file served over HTTPS from your domain, paired with the Associated Domains entitlement in your app and configuration in your Apple Developer account. The AASA file declares which URL paths your app should handle.

On Android, App Links use an assetlinks.json file hosted over HTTPS on your domain, with Digital Asset Links verification confirmed through the Google Play Console. The structure is parallel: a hosted file plus an app-side declaration that together prove your app is allowed to claim your domain's links.

// /.well-known/assetlinks.json (Android)
[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourcompany.app",
    "sha256_cert_fingerprints": ["AB:CD:..."]
  }
}]

Apple's TN3155, "Debugging Universal Links," exists precisely because this is where teams lose hours. Test the real install-from-store flow on a physical device, not the simulator, not a debug build sideloaded over USB. The verification behavior differs in those environments and a link that works in your test setup can be broken in production. A misconfigured association file is also the kind of avoidable detail that turns up as an app store rejection that quietly costs a shipping startup its launch date.

Deferred deep linking: the part that drives installs

A deferred deep link persists the intended destination until after a user installs the app, then routes them there on first open. The user taps a link to a specific product, has no app, gets sent to the store, installs, opens, and arrives at that exact product. The transition from web to in-app content stays intact across the install.

The single most important line of code in this entire flow is the SDK callback that fires on first launch. On both platforms, the deferred destination arrives through the same callback that handles a normal deep link, fired once when the app first opens. If you do not register and handle that callback, the destination is silently dropped and the user lands on your default screen. Every other piece can be perfect and this one missing handler erases the payoff.

When we build mobile apps that depend on referral loops or paid acquisition, this callback is treated as a launch-blocking requirement, not a nice-to-have, because it is the difference between a referral that converts and a referral that wastes the install. Treating that first screen as a designed arrival, with an app shell so users never stare at a spinner, is what keeps the momentum a deferred link bought you from leaking away on load. The same continuity logic applies whether you are shipping native or weighing whether a PWA beats a native app for your budget, since a PWA opened from a link skips the store round trip entirely.

Attribution: knowing what actually worked

Linking is about user experience. Attribution is about knowing where to spend your next dollar, and the two platforms handle it very differently.

Android gives you a clean answer. The Google Play Store's Install Referrer API lets you securely retrieve the tracking link that led to the install. On install, the Play Store passes a referrer string carrying the click token, which gives you a definitive one-to-one match between the click and the install. There is no guessing.

iOS does not offer this. There is no native API to retrieve the install referrer directly. Instead, attribution providers call an endpoint that attempts to return the tracking link most likely responsible for the install, often using probabilistic matching on signals available around the click and install times. The result is a best estimate, not a certainty, and you should treat iOS attribution numbers as directional rather than exact. Building your growth model on the assumption that iOS attribution is as precise as Android's is a quiet way to misread your own data.

The 2025 migration you may have missed

If your app still depends on Firebase Dynamic Links, you have a problem that is already past due. Google shut the service down effective August 25, 2025, which forced a large number of apps to migrate. The replacement is not another magic service that does everything; it is the native primitives described above, Universal Links and App Links, sometimes with a third-party SDK for the deferred and attribution layers on top. Teams that built on Dynamic Links and treated it as permanent infrastructure learned a useful lesson about depending on a hosted convenience for something this fundamental. It is the same calculus founders weigh when they decide what to build and what to buy before wasting a quarter: a black-box service is cheap until the day it disappears. The native platform mechanisms are not going anywhere, because they are the platforms themselves. The same lesson runs through any team that built on a hosted convenience instead of owning the primitive, which is part of why we lean toward shipping React Native updates the same day you write them over depending on a black box you cannot fix when it breaks.

A pre-launch checklist that actually catches the failures

These links break in ways that pass every casual test and fail in production. The verification has to mirror real conditions.

• Serve both association files over plain HTTPS with the correct content type, no redirects. A redirect on the AASA or assetlinks file is a common silent break.
• Register the first-launch callback before anything else in app startup. Confirm it fires with a real deferred link on a fresh install, not a reinstall over existing data.
• Test the full store round trip on physical devices for both platforms. Tap link, go to store, install, open, verify you land on the right screen. Do this for a user who has never had the app.
• Verify attribution end to end. Click a tracked link, install, and confirm the install shows up attributed to that click in your dashboard. On iOS, sanity-check that the probabilistic match is landing on the right campaign.
• Handle the cold-start race. If your link arrives before your app finishes initializing its router, buffer the destination and navigate once the app is ready. A destination that arrives before the screen exists gets dropped. This is the same class of startup ordering bug you fight server-side when you kill startup races with docker compose up --wait and healthchecks.

The outcome you are buying

When this is done right, the experience disappears, which is the point. A user shares a specific recipe with a friend. The friend taps it, does not have the app, installs from the store, opens it, and is looking at that exact recipe. Nothing felt lost. The friend never thought about the App Store as a detour. And on your side, you know that share drove an install, so you can double down on the loop that is working.

That continuity is worth real money in retention and acquisition, and it costs a few days of careful engineering plus a verification pass that takes the platform quirks seriously. The teams that win at mobile growth are not the ones with the cleverest funnels. They are the ones whose links simply never break, on either platform, across the install, every time.