Firebase Dynamic Links Alternative: What to Use Now That It's Shut Down

The short answer

Google shut down Firebase Dynamic Links on August 25, 2025. Every *.page.link URL stopped resolving, the Dynamic Links SDKs stopped returning deferred deep links, and there is no way to create new ones. Google did not ship a direct replacement.

What you should use instead depends on what Dynamic Links was doing for you:

Most apps used Dynamic Links for more than one of these, and the last three tend to come together. The rest of this guide walks through each path, then covers what to check before you pick a service and how to move without breaking links your users already have.

What stopped working

If your app still has Dynamic Links code in it, here is what it gets today:

• Old links go nowhere. A page.link URL in an old email, a printed QR code, a social post or someone's bookmarks no longer opens your app or your site.
• First launch returns nothing. Calls like getDynamicLink() or getInitialLink() come back empty, so a new user who installed from a link lands on your home screen instead of the content they tapped.
• Nothing new can be created. The console and buildShortLink() no longer create links, so any feature that generated share or invite links at runtime is broken.

The first one matters most if you printed links, because those can't be updated. The fix is to recreate the links you still need on a domain you control, so it can never happen again.

Path 1: Links that open your app (free, built into the OS)

If you only need a link to open your app when it's installed, and fall back to a web page when it isn't, iOS and Android already do this:

• iOS Universal Links. Host an apple-app-site-association file at https://yourdomain/.well-known/ and add the Associated Domains entitlement to your app.
• Android App Links. Host an assetlinks.json file at the same path and add a verified intent filter.

You can host both files on any HTTPS server, including Firebase Hosting. A link on your own domain also looks more trustworthy than page.link ever did.

What you don't get: if the app isn't installed, the user goes to the web page and stays there. There's no store redirect, no deferred deep linking, and no record of who clicked what. The details are also easy to get wrong, because iOS fails silently when the association file is off. Our AASA Validator checks the file for free, and Universal Links vs App Links explains how the two differ.

Path 2: Firebase Auth email links

If your app used Dynamic Links only to deliver passwordless sign-in or email verification links, you don't need a third-party service. Firebase Auth now sends those links through Firebase Hosting domains (*.firebaseapp.com, *.web.app, or a custom domain on Firebase Hosting). Update the Firebase Auth SDK, set linkDomain in your ActionCodeSettings, and follow Firebase's guide on migrating email link authentication away from Dynamic Links.

Path 3: Deferred deep linking and attribution (a service)

This is the part of Dynamic Links that is genuinely hard to replace yourself. Deferred deep linking means a person taps a link, installs your app, opens it for the first time, and lands on the exact thing they tapped: the product, the invite, the shared post. The operating system doesn't do this for you, because the install breaks the chain between the tap and the app.

A deep linking service closes that gap. Its SDK reports the new install on first launch, the service finds the click the install came from, and the app receives that link's data. Most services also give you what Dynamic Links never did well: reporting on clicks, installs and what users do afterwards.

Several hosted services cover this. LinkForty is ours, and it was built for exactly this migration. The migration guide maps every Dynamic Links concept to its replacement.

Path 4: Build it yourself

You can rebuild Dynamic Links in-house. It's worth knowing what that means before you start:

• A redirect service on your own domain that tells phones, desktops and in-app browsers apart and sends each to the right place
• The apple-app-site-association and assetlinks.json files, kept correct as your app IDs and signing keys change
• Link creation, for the dashboard and from inside your app
• Social preview tags, so links show a title and image when they're shared
• Deferred deep linking: storing each click, then matching a new install to it on first launch, without IDFA and without asking for tracking permission
• Analytics on clicks and installs, if you want to know which links work

The first three are a few days of work. Matching installs to clicks reliably, and handling the in-app browsers in Instagram, Gmail and LinkedIn that skip Universal Links, is where homegrown versions usually fall short.

What to look for in any replacement

Whatever you choose, check these before you commit:

1. Deferred deep linking on iOS without IDFA. Apple's tracking rules mean a service shouldn't need the App Tracking Transparency prompt to match installs to clicks. Ask how it matches, and what it tells your app when it isn't sure.
2. In-app browsers. A lot of taps happen inside Instagram, Facebook, Gmail and similar apps, which bypass Universal Links. Ask what a link does there.
3. Your own domain. Links on your domain survive any future vendor change. Make sure the service hosts the association files on it for you.
4. An SDK for your stack. Expo, React Native, Flutter, native iOS and native Android each need their own.
5. What happens after the click. Knowing a link was tapped is the minimum. Knowing it led to a sign-up or a purchase is what makes links worth managing.
6. A way out. Dynamic Links taught everyone what happens when a link provider disappears. Export, an open-source core, or both, mean you're never stranded again.

Moving from Dynamic Links to LinkForty

LinkForty covers what Dynamic Links did, on your own domain, and adds reporting on what happens after the click.

How matching works. On Android, an install from Google Play is matched to the exact click through the Play install referrer. Everything else is matched without device IDs, using the network, platform, OS version, time zone and language, within a window you set per link, from 5 minutes to 90 days (7 days by default). No IDFA and no tracking prompt. When another link also had a qualifying click from the same network, your app is told, so a sign-in or gift link can ask the user to confirm before acting on it. Deferred deep linking in LinkForty covers the details.

In-app browsers. Inside Instagram, Facebook, Gmail, LinkedIn and similar apps, LinkForty sends people to your web fallback instead of the store, because those browsers skip Universal Links and the web page gets a second chance to open your app.

After the click. When someone opens your app from a link, their in-app events and revenue are credited to that link, last click wins. When a link sends them to your website instead, the web pixel credits sign-ups and purchases there to the link. You see which links bring people who actually do something, on the surface they landed on.

SDKs. Open source, for Expo, React Native, Flutter, iOS and Android.

The order that keeps your users working

1. Create a workspace and pick your link host: your own subdomain, or the toapp.me host. Enter your Team ID, bundle ID, package name and signing fingerprint so the association files are served.
2. Recreate the links you still need. Firebase's links went away with the service, so there's nothing to export from it. Create them in the dashboard, through the API, or in bulk from a CSV.
3. Install the SDK and swap the listeners. Point the LinkForty callbacks at the same screens your Dynamic Links handlers opened.
4. Verify. A fresh install from a LinkForty link should land on the right screen and show up under Installs, and a tap with the app installed should open it directly.
5. Remove the Dynamic Links SDK last, in its own commit, once step 4 holds.

Steps 3 to 5 are mostly mechanical, so the migration guide includes a prompt that has Claude Code, Cursor or Codex do them in your project. It inventories every Dynamic Links call first, asks which screen each link should open instead of guessing, and removes the old SDK only after the new one works.

Common questions

Do old page.link links still work? No. They stopped resolving when the service shut down. Recreate the ones you still need on your own domain, and update any you can still edit.

Can I import my Dynamic Links into LinkForty? Not directly: Firebase's links can't be exported now that the service is gone. If you kept a list of them, a CSV import recreates them in bulk.

Do I need IDFA or the App Tracking Transparency prompt? No. LinkForty's SDKs don't collect IDFA or GAID and never show the tracking prompt.

Does it work with Expo, React Native and Flutter? Yes. Each has its own open-source SDK, alongside native iOS and Android.

Is there a free plan? Yes, with no card required. Deferred deep linking, every SDK and the analytics are on the free plan; paid plans raise limits such as total links, custom domains and how long analytics are kept. See pricing.

Can I host it myself? Yes. The engine, LinkForty Core, is open source under AGPL-3.0: redirects, click analytics, deferred deep linking and the association files. The self-hosting guide covers setup. The hosted service adds the dashboard, teams, custom-domain SSL and the rest.