Blog

Firebase Dynamic Links Replacement: Migration Guide

Lakshith Dinesh

Lakshith Dinesh

Head of Growth, Linkrunner

Last updated on 9 min read

Firebase Dynamic Links Replacement: Migration Guide

Firebase Dynamic Links is no longer a service you can lean on. Google shut it down on 25 August 2025, and its own deprecation FAQ says every clicked link now returns an HTTP 404 to the user, whether it sits on a page.link subdomain or your own custom domain.

That is a hard failure, not a slow decline. If a QR code on your packaging, a link in last year's onboarding email or an influencer's bio still points to a Firebase Dynamic Link, the person tapping it lands on an error page. And because the SDK does not crash your app when this happens, the damage rarely shows up as an alert. It shows up as installs that never arrive and new users who open the app to a blank home screen.

This guide covers what the shutdown means now, what has broken, how to audit your exposure, how to choose a replacement and how to run the migration step by step.

What Is Firebase Dynamic Links, and What Did the Shutdown Change?

Firebase Dynamic Links: a free Google service that created smart links which opened the right screen in an installed app, sent new users to the App Store or Google Play, and carried that destination through the install so the app could open it on first launch.

For years it was the default free option for routing users from email, SMS, social bios and ads into an app. Its core value was deferred deep linking: remembering where a user was trying to go even when they had to install the app first.

According to the official Firebase Dynamic Links deprecation FAQ, the shutdown changed four things:

  • Links stopped resolving. Links on custom domains and page.link subdomains stopped working, and clicks return a 404. Errors were rolled out gradually from 25 August 2025 until they reached every request.
  • You cannot create links. The Short Links API and Link Stats API return 400 or 403 errors.
  • page.link domains are gone. Google confirms they cannot be kept or transferred, and URL prefix domains were deleted automatically.
  • Link metadata is marked for deletion and purged under Google's data retention policy.

Google's stated reason is that ecosystem changes affected its ability to deliver a stable post-install experience, which is exactly the deferred routing most teams relied on.

What Breaks When Your Links Return 404

The failures are spread across every channel that ever carried a Dynamic Link, which is why they are easy to miss.

Links in the wild

  • Paid campaigns with Dynamic Link destinations send users to an error page instead of the app or store.
  • CRM, push, WhatsApp and SMS templates keep sending dead links until someone edits each template.
  • QR codes on packaging, menus, posters and event material cannot be edited after printing. This is usually the most expensive fix, because it means reprinting.
  • Social bios, pinned posts and store listing text often hold links nobody has looked at in years.

Deferred deep linking

The Firebase FAQ's SDK tables are specific about what happens inside the app:

  • On iOS, first open attribution returns a 400 with no error emitted, and an empty Dynamic Link object comes back.
  • On Android, the link lookup reports success but returns empty data.

So the app does not crash. It simply opens new users to the default screen with no campaign context, and the referral code, product page or promo that brought them in is lost.

Attribution and analytics

Firebase Dynamic Links only ever offered link-level click analytics, not campaign-level install attribution tied to events and revenue. With the APIs switched off, even that click data has stopped flowing. Any report that used Dynamic Link clicks as a proxy for channel performance now has a hole in it.

There is a knock-on effect for Firebase Authentication too. Google's FAQ notes that email link sign-in, password reset and email verification in older app versions that have not moved to the updated Authentication SDK no longer work.

Audit Checklist: Find Every Dynamic Link You Still Depend On

Run this before you touch the SDK. Most teams find more integration points than they expected, and the QR and CRM channels are the ones most often overlooked.

In the codebase

  • Search for DynamicLinks and firebase.dynamicLinks imports
  • Check your Podfile (iOS) and build.gradle (Android) for Dynamic Links dependencies
  • Review the AppDelegate and MainActivity handlers that read incoming Dynamic Links
  • Check whether Firebase Authentication email links depend on Dynamic Links
  • If you hosted a custom domain on Firebase Hosting, review the Dynamic Links rewrite rules in firebase.json

Domains and link data

  • List every page.link prefix and custom domain your project used
  • If your project data is still available, export link metadata through Google Takeout, which the Firebase export guide describes as one CSV per domain, including the deep link, fallback and UTM parameters

Channels

  • Active paid campaign destination URLs
  • Email, push, WhatsApp and SMS templates in your CRM
  • QR codes on printed and out-of-home material
  • Social bios, pinned posts, partner and influencer links
  • App Store and Google Play listing copy

For each link you find, record the channel, the in-app destination and the parameters it carried. That table becomes your migration map.

How to Choose a Firebase Dynamic Links Replacement

Google's FAQ gives two official routes, and the right one depends on whether you need deferred deep linking.

What you needGoogle's suggested routeTrade-off
Open an already-installed app onlyUniversal Links on iOS and App Links on Android, optionally hosted on Firebase HostingNo context survives an install, and no attribution
Full feature parity, including deferred deep linking and click analyticsA third-party deep linking provider. Google names Adjust, Airbridge, AppsFlyer, Bitly, Branch, Kochava and Singular, noting it has not vetted themCosts money, so pricing model matters
Nothing (links no longer used)Export links, delete URL prefixes, remove the SDKNone

Building deferred routing in-house is a third option, but it means running a server that stores link context, resolves it after install and keeps pace with every iOS and Android change. Few growth-stage teams find that a good use of engineering time.

If you are choosing a provider, judge it on what Firebase Dynamic Links was weak at, not just on price:

  • Deferred deep linking that survives the store. Ask how context is matched after install on iOS and Android, and test it on real devices.
  • Attribution in the same SDK. A link tool that cannot connect a click to installs, events and revenue replaces one measurement gap with another. This is where a mobile measurement partner with built-in deep linking differs from a pure link router.
  • Custom domain support, so you can point a domain you control at the new provider and avoid hard-coding someone else's subdomain again. Our guide to setting up custom link domains for branded deep links covers DNS, SSL and verification files.
  • Payload parity. The new links must carry the same parameters your app's routing code expects.
  • Predictable pricing. You are moving from free to paid, so per-install or usage-based pricing is easier to justify than seat-based enterprise contracts.

For a wider view of the options, see how to choose a deep linking tool.

Step-by-Step Migration Plan

  1. Freeze new Dynamic Link usage. Stop anyone on the team creating new links that reference old domains or templates.
  2. Build the migration map from your audit: old link, channel, destination screen, parameters, owner.
  3. Set up your new link domain. Use a domain you own, configure DNS and SSL, and publish the apple-app-site-association and assetlinks.json files. Our AASA configuration guide covers the iOS side in detail.
  4. Swap the SDK. Remove the Dynamic Links dependency and handlers, add the new SDK and route both direct opens and deferred opens through one handler that reads the same parameters.
  5. Handle Firebase Auth email links if you use them, by upgrading the Authentication SDK as Google's FAQ describes.
  6. Recreate links channel by channel, starting with live paid campaigns, then CRM templates, then social and partner links.
  7. Replace QR codes on the next print run, and use a domain you control this time so future changes need no reprint.
  8. Test on real devices across installed, not installed, iOS and Android, and in-app browsers. Use a deep link QA checklist before any campaign goes live.
  9. Validate attribution. Click your own test links, install, and confirm the install and first events land against the right campaign in your dashboard.
  10. Remove the Firebase Dynamic Links SDK and delete leftover URL prefixes once nothing depends on them.

Tech Explainer: deferred context is only preserved if the app asks for it on first launch. If your old code read the Dynamic Link inside a screen that loads after onboarding, move the lookup to app start in the new implementation, or the context will arrive too late. Our explainer on how deferred deep links preserve context through install walks through the mechanics.

Where Linkrunner fits

Linkrunner is an MMP that unifies deep linking and attribution in one SDK. Every link it creates is dynamic and deferred by default, it supports Universal Links, App Links and branded short links on custom domains, and each click is tied through to installs, in-app events and revenue. SDK integration typically takes 2 to 4 hours.

Pricing starts with 25k free attributed installs, then runs from $0.010 down to $0.007 per attributed install, postpaid, with no separate deep linking charge. Stratzy is one of the teams that moved off Firebase Dynamic Links to Linkrunner, and with attribution in place it could see which campaigns were driving higher ROAS. The Firebase Dynamic Links migration page and the deferred deep linking docs cover the setup.

Frequently Asked Questions

When did Firebase Dynamic Links shut down?

Google shut Firebase Dynamic Links down on 25 August 2025. Error responses started gradually from that date and rose to cover every request. Clicked links now return an HTTP 404.

Can I keep my page.link domain?

No. Google's FAQ states that page.link domains cannot be kept or transferred after shutdown, and URL prefix domains were deleted automatically. Use a domain you own for the replacement.

Will the Firebase Dynamic Links SDK crash my app?

No. Google says the SDKs will not crash, but they return errors or empty data. Your app has to handle that, which in practice means removing the SDK and routing through a replacement.

Can I still export my old link data?

Google documents a Google Takeout export that produces one CSV per domain. Link metadata was marked for deletion at shutdown and is purged under Google's retention policy, so try the export now if you still need it.

Are Universal Links and App Links enough on their own?

Only if every user already has the app installed. They do not carry context through an install and provide no attribution, so most growth teams pair them with a deferred deep linking and attribution provider.

Your Next Step

The shutdown already happened, so the cost of waiting is measured in broken links that are live today. Run the audit checklist this week, fix paid and CRM links first, and plan QR replacements for the next print run.

If you want deep linking and attribution handled in one place, request a demo from Linkrunner and walk through your migration map with the team.

Start measuring the installs your team cares about

Bring attribution, deep links, SKAN, cohorts, and campaign intelligence into one workflow your growth team can trust.