Deep Links and Deferred Deep Links for Mobile Games in 2026: How They Work on Android and iOS, What Replaced Firebase Dynamic Links, Where Games Use Them, and a QA Checklist

Someone taps the link in a creator's video description, installs your game, and opens it for the first time. Do they land on the limited-edition skin the video promised, or on the same first tutorial screen as every other new player? Deep links and deferred deep links decide that. A deep link sends someone who already has the app to a specific screen inside it. A deferred deep link takes someone who doesn't have the app yet through the store and the install, then carries them to that screen on first launch.

There are three reasons to revisit this in 2026. First, Firebase Dynamic Links, which many studios used for free, shut down on August 25, 2025, and old links now return HTTP 404. Second, the replacement Google recommends, App Links and Universal Links, only handles apps that are already installed, so deferred deep linking has to be solved separately. Third, on iOS, pasteboard access notices and Apple's ban on fingerprinting leave far fewer ways than on Android to connect a pre-install click with the first post-install launch. Based on Android Developers, Apple Developer, and Firebase documentation as of November 2026, this article covers how each OS works, where games use links, and the test matrix to run before launch.

Deep linking often gets mixed up with attribution, which counts who gets credit for an install. The two share the same link but solve different problems. We covered the attribution side in Why Every Dashboard Shows a Different Install Count: A Game Marketer's Guide to Mobile Attribution in 2026. This article covers routing: where the person who clicked actually ends up.

What Are Deep Links, App Links, Universal Links, and Deferred Deep Links?

A deep link is any link that points to a specific screen inside an app. App Links (Android) and Universal Links (iOS) verify that you own a website so that an ordinary https address opens the app directly. A deferred deep link carries the same destination to someone who doesn't have the app yet, so it still applies on their first launch after install.

As the table shows, App Links and Universal Links only open a web page for someone without the app. Sending them to the store and restoring the original destination after install is not something the OS does for you. Link services like Firebase Dynamic Links used to fill that gap. Today an MMP (mobile measurement partner), a dedicated deep linking vendor, or an in-house build does that job.

From a game design point of view, one more distinction matters. A link carries a destination ("which screen") and parameters ("in what context"). If someone arriving with creator A's code and someone arriving from a lapsed-player push should get different rewards on the same event screen, parameter design matters as much as destination design. Apple warns that both Universal Links and custom schemes are a potential attack vector, and says to validate every URL parameter and never let a link alone delete data or access sensitive information. That is also why a reward should never be confirmed by a link parameter alone. The safe pattern is for the server to verify the code and its usage history before granting a reward, and for the link to decide only which screen opens.

How Does Deferred Deep Linking Work on Android?

On Android, deferred deep linking normally works through the referrer value Google Play stores at install time. The app reads it on first launch through the Play Install Referrer API, and the value stays available for 90 days after install.

Here is how it works. When an ad or link page sends a user to the Google Play store URL, it carries campaign or destination data in the referrer parameter. When the user installs and opens the app for the first time, the app connects to the Play Store app through the Play Install Referrer library and gets the referrer URL, the referrer click timestamp, the install begin timestamp, the app version at first install, and more. Android documentation describes the API as a way to "securely" retrieve referral content from Google Play, and says devices with Play Store app version 8.3.73 or later have it automatically. The referrer information is available for 90 days and won't change unless the app is reinstalled, so Google recommends calling the API only once, on the first run after install.

For installed users, App Links got stricter with Android 12. Starting in Android 12 (API level 31), a generic web intent opens your app only if your app is approved for that domain. Otherwise it opens in the user's default browser. You get approval either by verifying the domain with App Links or by having the user associate the app with the domain in system settings. The verification file, assetlinks.json, must sit at https://domain/.well-known/assetlinks.json, be served as application/json over HTTPS with no 301 or 302 redirects, and be published on every domain your links use.

The most common failure point for studios is the signing certificate fingerprint. Google's documentation warns that if you use Play App Signing, the fingerprint you generate locally with keytool usually won't match the one on users' devices, and points you to the app signing page in Play Console for the correct Digital Asset Links JSON snippet. If links open fine in development builds but fall back to the browser only in the store build, this is the first thing to check.

Two more changes are worth knowing in 2026. Dynamic App Links, introduced with Android 15, let you define path, query, and fragment rules on the server side inside assetlinks.json, and use exclude so certain URLs open in the browser instead of the app. Server rules can't widen the scope declared in the app manifest, so Google recommends declaring broad scope in the manifest (scheme and domain) and refining paths with server rules. Propagation speed differs, though. Devices on Android 15 and later re-verify periodically in the background, and changes can take up to seven days to reach all devices. Android 14 and lower don't re-verify periodically and usually pick up changes only when the app is installed or updated. Editing assetlinks.json the day before an event goes live is risky.

The Deep links page in Play Console (Grow users > Deep links) is also useful. It validates the domains and intent filters declared in each app version's manifest and shows what failed, and it lets you create patches that add web links or turn off specific paths without releasing a new app version. Patches are not kept in future app versions, though, so the change has to go into the manifest in your next release.

One more point on opening the app from a web page. Chrome's intent:// URLs can name a fallback with the S.browser_fallback_url parameter for users without the app. But Chrome won't launch an external app when a JavaScript timer tries to open it without a user gesture, or when the intent is redirected from a URL typed into the address bar. That is one reason a landing page that "automatically hands off to the app" looks stuck in some environments. A design that waits for one user action, such as a button tap, is more reliable.

Why Is Deferred Deep Linking Harder on iOS?

iOS has no official channel equivalent to the Play Install Referrer through which the store hands click data to the app. The methods that filled that gap, device-signal matching and the clipboard, are constrained by Apple policy and by OS notices and permission prompts.

Start with Universal Links for installed users. According to Apple, Universal Links are standard http and https URLs, so one URL works for both the website and the app, and if the app isn't installed, the website opens in the default browser. When someone installs the app, the system checks the AASA file on your web server to verify the association. Since macOS 11 and iOS 14, that request goes to an Apple-managed CDN rather than directly to your server. Apple's CDN requests your domain's AASA file within 24 hours, and devices check for updates roughly once a week after install. Each subdomain needs its own entry and its own AASA file, served over https with a valid certificate and no redirects.

Apple also documents when a Universal Link won't open the app. If a user browsing your site in Safari taps a Universal Link on the same domain, the system keeps it in Safari, respecting the user's likely intent to stay in the browser. A link to a different domain opens the app. That is why an "Open in app" button on an event landing page fails when the landing page and the deep link share a domain. AASA components rules apply in order, the first match wins, and exclude keeps specific paths out of the app.

For deferred deep linking, the options narrow.

The takeaway is not "there is no 100% accurate method on iOS" but "few methods are both accurate and policy-compliant." Many link vendors advertise iOS match rates, but their measurement methods differ, so the numbers are hard to compare, and we don't cite them here. In practice, it is safer to plan on the assumption that deferred deep links will sometimes fail on iOS. For a creator reward, for example, apply it automatically when the link is restored, and when it isn't, let the player enter the code or use a paste button on the first screen. A paste button is an explicit user action, so it doesn't trigger the iOS 16 approval prompt.

ATT matters here too. In its deep linking FAQ, Apple says that if a third-party service your app uses passes unique identifiers or creates a shared identity of the user between apps from different companies for ad targeting, ad measurement, or sharing with a data broker, you must use ATT. If the same SDK handles link routing and ad measurement, check with your privacy lead what it sends and where. For measuring re-engagement ads, Apple's AdAttributionKit, available from iOS 17.4, supports re-engagement conversions, so you can design links and measurement separately.

What Did Studios Move to After Firebase Dynamic Links Shut Down?

Firebase Dynamic Links shut down on August 25, 2025. Google's guidance was to move to another deep linking provider if you need the full feature set, or to App Links and Universal Links if you only need to open installed apps.

According to the Firebase FAQ, after the shutdown, links on custom domains and page.link subdomains return HTTP 404, no new links can be created, and the Short Links and Link Stats APIs return 400 or 403 errors. URL prefix domains were deleted automatically after the shutdown date, and domain and link metadata is purged under Google's data retention policy. On the app side, First Open Attribution calls return a 400 error: an empty object on iOS and a success response with empty data on Android. If an old app version decides routing from that response, it may be silently sending everyone to the default screen without any error.

Firebase's migration guide to App Links and Universal Links states in a table that this path does not send users to the right store for their device, does not continue the user's journey after download, install, and first open, does not provide link click analytics, and does not create short links. It mentions iOS Smart App Banners as a partial alternative for store routing and deferred linking. In other words, "we moved to App Links and Universal Links" means links for existing players are solved, not deferred deep linking for new players.

Checking whether the migration is really done is simple: search ad creatives, creator briefs, community posts, support macros, and URLs hardcoded in old app versions for page.link or your old FDL custom domain. If your game handled email-link sign-in or password resets through Firebase Auth, Firebase says you must upgrade to the latest Auth SDK and that older app versions without the new solution will lose those features, so check your account recovery flow as well.

Where Do Games Use Deep Links and Deferred Deep Links?

In games, the value of a link is that it shows the promised thing on the first screen. The main use cases are routing ad and creator traffic, re-engaging lapsed players, invite links, web shop links, and pre-registration.

The most common mistake with ad and creator traffic is setting the destination too deep. Dropping a new player straight into PvP with no tutorial makes the first experience worse. The link's job is to remember the promise and keep it at the right moment, so guiding the player to the reward or mode when the tutorial ends, or on first lobby entry, usually works. Giving each creator a different destination and reward keeps what the creator says on video consistent with what happens in the game.

The effect is even clearer in re-engagement. If you send a lapsed player a push or ad that says "claim your new season reward" and the app opens on the home screen where they have to hunt for it, the promise turns into one more tap. Google's App campaigns for engagement (ACe) include deep links in their entry requirements. Re-engagement messaging and reward design are covered in Winning Back Lapsed Mobile Game Players: A Re-engagement Framework That Works.

Invite links are where a failed deferred deep link costs the most. If a player installs from a friend's invite and isn't connected to that friend on first launch, the invitee becomes just another solo new player, the inviter gets no reward, and the next invite never gets sent. When you calculate an invite feature's K-factor, measured invites come from deep link and referral data, so a low link restoration rate also makes the viral effect look smaller than it is. For calculating invite metrics, see Viral Coefficient and Organic Uplift in Mobile Games: How to Calculate Them, What Realistic Values Look Like, and the Traps in Building Them Into eCPI.

Web shops have the opposite problem. If the web shop and event pages share a domain and you register the whole domain for App Links and Universal Links, tapping a web shop link opens the app and the player never reaches checkout. The baseline is to use AASA exclude rules and Android 15+ Dynamic App Links exclude rules to keep web shop paths out of app handling, and let only the "back to game" link after payment open the app. The broader web shop traffic problem is covered in Mobile Game Web Shops: A $17 Billion Channel Whose Real Problem Is Traffic.

Pre-registration is where you can expect the least from links. Weeks or months pass between a pre-registration click and the launch-day install, and the install often happens through a store notification or auto-install. Rather than assuming click-time link data survives to the first launch on launch day, it is more realistic to deliver pre-registration rewards through the store's pre-registration reward features or by account, and use links to tell apart the sources of traffic to the pre-registration page. How the two stores differ on pre-registration is covered in How App Store Pre-Orders and Google Play Pre-Registration Differ for a Mobile Game Launch: Setup, Launch Day, Rewards, and a 12-Week Plan.

Where Do Deep Links Break?

Most deep link failures come not from code but from domain verification files, signing certificates, same-domain rules, in-app browsers, and the order of operations at first launch.

The in-app webview row matters most for creator marketing. When someone taps a link inside a video platform, social network, or messaging app, the page often opens in that app's built-in browser. How each built-in browser handles Universal Links and intents varies by app and version, and there are no published official rules. That means this area can't be confirmed from documentation. The only option is to pick the apps that send you the most traffic and test them on real devices regularly. The most universal fix is to put both a "Get it on the store" button and an "Open app" button on the landing page, and make both work on a user tap.

First-launch ordering is also easy to miss. A game's first launch packs in resource downloads, terms acceptance, account creation, and the tutorial, so a long time passes between receiving the link data and using it. The structure that breaks least is to fetch the link data right after launch, store it locally and on the server, and do the actual routing by reading the stored value when the tutorial ends.

Pre-Launch QA Checklist: What to Test, in Which Combinations?

Deep link QA has to cover combinations of three axes: OS, whether the app is installed, and where the link is tapped. We recommend running at least the matrix below before every campaign and after every app update or domain change.

There are operational checks beyond the matrix. Track every campaign's link destination, parameters, owner, and expiry date in one sheet, so links from ended events don't land on empty screens. On each app update, confirm that the manifest intent filters and AASA and assetlinks.json changed together, and recheck the new version's results on the Play Console Deep links page. Include test devices on both Android 14 and lower and Android 15 and later to catch the difference in how assetlinks.json updates propagate. Finally, record link clicks, installs, and successful first-launch destination restores separately, so you can spot immediately which OS, environment, or campaign is losing restorations. When you need to tell whether a link or a creative is hurting performance, that number is the first one you need.

Traffic from ad media needs the same checks. Playio is an Android-based community of 5 million gamers who love games, and it connects games with gamers whose tastes match, using genre preferences, play history, and in-game behavior data. Pricing is CPI by default, and CPE based on in-game actions such as tutorial completion, reaching a level, or hitting a playtime goal is also supported. In campaigns that target in-game actions, results depend on whether installed players get from first launch to the target action without friction, so we recommend checking the Android installed and not-installed paths together before the campaign starts.

You can find more details here. (https://playioadsen.oopy.io/bizdeck)

Key Takeaways

A deep link opens a specific screen in an installed app. A deferred deep link carries the same destination to someone without the app, through the store and the install, to their first launch. As of November 2026, on Android the Install Referrer passed by Google Play (kept for 90 days after install, called once on first launch) is the default path for deferred deep links. Since Android 12, web links open in the browser unless App Links are verified, and since Android 15, server rules in assetlinks.json can adjust paths, though changes can take up to seven days to propagate. iOS has no equivalent of a store referrer, Apple prohibits device-signal identification, and clipboard reads trigger a notice since iOS 14 and an approval prompt since iOS 16. You therefore need a fallback flow where players can still reach the promised reward through code entry or a paste button when a deferred deep link fails. Firebase Dynamic Links shut down on August 25, 2025, and the App Links and Universal Links path Google recommended handles only installed apps, so deferred deep linking for new players has to come from another vendor or an in-house build. Games use links for ad and creator traffic, re-engagement, invites, web shops, and pre-registration, and each use case needs different choices on destination timing, server-side reward verification, and exclude rules. Most failures come from verification files, signing fingerprints, same-domain rules, in-app browsers, and first-launch ordering. The surest way to manage them is to run the OS × install state × entry environment matrix before every campaign and app update, and to record destination restores as their own metric.

For inquiries about Playio's advertising solutions, reach out at: [email protected]