Firebase Dynamic Links is shut down — here is the replacement path

Firebase Dynamic Links shut down on August 25, 2025. The hosted page.link and custom-domain links stopped resolving on that date, and Google's own documentation has been pointing teams to alternatives since. If you are reading this because your links went dark, or because you are planning the migration before the next release forces it, this is the replacement path — including what most migration guides leave out.

The short version: replacing Dynamic Links does not require adopting an attribution suite. A deep-linking replacement needs four things — a link schema that survives migration, deferred matching after install, managed association files, and a migration toolchain that does not take a quarter. We built LocusVia to satisfy exactly those four, and the migration guide documents the contract in full. Here is the reasoning.

What actually broke

Three things die with Dynamic Links, and they break differently:

1. Existing links. Every page.link and custom-domain Dynamic Link stopped resolving after shutdown. If you did not migrate, your SMS, email, and QR links are dead links that open nothing or land on an error page.
2. Deferred continuation. The capability that resumed a user's journey after install — tap a link, install, open the app, land in the right place — went away with the service.
3. Hidden dependencies. Firebase email-link authentication, password reset, and email verification retained a Dynamic Links dependency for some SDK versions, which means parts of your auth flow could break independently of your marketing links. Google published migration guides for iOS and Android.

So a complete migration is two migrations: your links and the auth flows that silently depended on them. Checklists that only cover the links are incomplete.

What a replacement must provide

Same link schema

The migration cost is dominated by the shape of your URLs. If the replacement requires a different link format, every printed QR code, SMS template, and campaign parameter mapping needs to change.

LocusVia's short-link schema is compatible with the link shapes your team already knows: a branded host, a slug, and query parameters that carry the route and campaign context. That means the migration is mostly re-issuing links against the new host, not redesigning your link model. The short-link documentation shows the resolution contract.

Deferred matching after install

Dynamic Links' deferred continuation was the feature teams leaned on most: the install-time handoff that lands a new user in the right place with the right context. The replacement must keep that behavior, and ideally make it more deterministic.

LocusVia captures a route snapshot at click time, stores it behind a single-use token with a 30-minute TTL, and lets the SDK redeem it after install keyed by a hashed fingerprint. Deterministic by default, with no probabilistic identity guessing — and no PII in the matching record. The deep-link pipeline documents the full sequence: click, snapshot, install, redemption, consumption.

The honest comparison is that Dynamic Links-era deferred matching was often probabilistic under the hood. A replacement that continues to guess which click produced an install is fine for marketing analytics and wrong for routing — restoring an order, an auth flow, or a document after install should never depend on a statistical model. Deterministic snapshots are the correct baseline.

Managed association files

Dynamic Links managed the platform plumbing for you. If you are rebuilding that plumbing by hand — editing apple-app-site-association and assetlinks.json yourself — you are also taking on its failure modes: expired certs, wrong team IDs, missing signing fingerprints, and the silent breakage where the app simply stops opening links.

LocusVia generates and serves the association files for your managed domains, backed by readiness diagnostics and auto-healing verification that re-issues associations when they drift. The domains documentation covers the association contract.

A migration toolchain

The difference between a migration that ships in a week and one that ships in a quarter is tooling: link inventory export/import, dry runs, and a swap that is verifiable before cutover.

LocusVia ships bulk import/export with mapping review — old link, new URL, deep route, platform bundle IDs, store URLs, campaign metadata, fallback URL — and a dry-run path so you can validate mappings before anything goes live. The migration guide shows the mapping contract.

The SDK swap

For React Native teams, the client-side swap is deliberately small. The LocusVia SDK mirrors the integration surface teams already know, so the change is a three-line diff: replace the provider import and point the base URL at your LocusVia host, keeping the same deep-link resolution calls.

- import { FirebaseDynamicLinks } from "@react-native-firebase/dynamic-links";
+ import { LocusViaProvider } from "@locusvia/react-native-sdk";

<LocusViaProvider
  config={{
    appID: "app_your_app",
    apiKey: "your_api_key",
    baseUrl: "https://api.locusvia.com",
  }}
>
  <App />
</LocusViaProvider>

Same for native: point your app identity at LocusVia's managed association files and use the SDK's deferred resolution. If the swap diff is bigger than this on your platform, the vendor is making you rebuild more than you need to.

The decision that matters: linking product or attribution suite

The biggest trap in the current replacement market is scope creep. The platforms with the largest share of the "Firebase replacement" SERPs are measurement platforms first: they will happily host your links, but the actual product is attribution, predictive modeling, and marketing analytics — with pricing and onboarding shaped accordingly. Your team needs a linking infrastructure with diagnostics, not another vendor that wants to become the center of your measurement stack.

That is why LocusVia is deliberately a deep-linking control plane: routing, deferred matching, association management, per-click diagnostics, and auditability — without an attribution suite around it. The free tier exists precisely so the replacement decision is made on the technical contract, not a sales cycle: $0/month, one managed domain, 100 links, and 10K resolutions per month, with transparent pricing above that.

The migration checklist

Regardless of vendor, the migration has the same shape. Use this as your cutover list:

1. Inventory. Export every live Dynamic Link: short links, QR codes, SMS templates, email templates, deep routes, and store/fallback URLs.
2. Find hidden dependencies. Grep for firebase.*link and FirebaseDynamicLinks usage — including email-link auth. Fix those flows against Google's auth migration guides first.
3. Map. Old link → new branded URL → deep route → platform bundle/package IDs → store URLs → fallback URL → campaign metadata.
4. Dry-run. Import into the replacement with mapping review; validate before cutover.
5. Cut over. Re-issue links against the new host; keep old hosts serving a 302 or an explanation page while traffic drains.
6. Verify per click. After cutover, confirm a real device journey: app open, fallback shown, deferred resolution after a fresh install — using per-click diagnostics, not dashboards.

The quickstart takes about 15 minutes from a managed domain to a production-ready mobile route, which makes step 5 a same-day event instead of a project. And if you want the deeper architecture reasoning behind the deterministic-deferred decision, the enterprise deep-linking platform post covers it.

The shutdown happened. The second outage — the one where the replacement platform makes you rebuild your link model, adopt an attribution suite you did not ask for, or sign up to a sales-led enterprise contract to get basic deferred matching — is the one you can avoid.