A Firebase Dynamic Links alternative for people who just need the link to work

Start here: which job were you using?

One URL did two jobs — routing to the right store, and deferred deep linking with install attribution — and that is why the replacement question feels harder than it is; separate them before you shop.

1. Routing. One URL that resolves per device — App Store or Play — with a page built from the store listing and, on paid plans, an optional separate desktop target.
2. Deferred deep linking and attribution. A payload that survives the install so a brand-new user lands on the right screen, plus a record of which campaign produced which install.

If you were only using the first, most of Google’s list is far too big for you and you can be done today. If you were using the second, you need a measurement platform and no link tool will substitute for one. Plenty of teams were using the first and assumed they needed the second, which is how a two-hour migration turns into a procurement exercise.

What shut down on 25 August 2025, and what is unrecoverable?

Google’s own note is in the Firebase Dynamic Links FAQ.

Firebase Dynamic Links was turned off on 25 August 2025. This was not a soft deprecation with a redirect period: every page.link URL the service ever issued now returns a 404. A link printed in a README, pasted into an Instagram bio, or embedded in an email two years ago is a dead end today, and no console setting brings it back.

Two consequences follow. Every page.link URL you control must be replaced by hand, and every page.link you cannot edit — a printed QR code, a link inside an already-shipped app build, a post someone else wrote — is unrecoverable with any replacement product, because the redirect that made it work no longer exists.

Why Google’s list may not fit you

The deprecation FAQ names seven replacements: Adjust, Airbridge, AppsFlyer, Bitly, Branch, Kochava and Singular. It lists them flat, and says outright that Google has not vetted them. The categories below are ours.

Six of the seven are measurement platforms. That is not a criticism — they are good at measurement, and if Dynamic Links was carrying your install attribution then one of them is the correct answer and their migration guides are where to go next. But a measurement platform asks for an SDK in your app, a plan sized around monthly install volume, and usually a conversation with sales before you have a working URL.

The developer whose Dynamic Link was doing nothing more complicated than send an iPhone to the App Store and everyone else to Play has no entry on that list sized to the problem. That is the gap this page is about.

Which replacement is best for your case?

There is no single best answer, and any page that gives you one has skipped the question that decides it. Match the row you are in rather than the product with the longest feature list.

The last row is the one most often missed: the two are not mutually exclusive, so if you end up on a platform for the attribution half, an AppIn link can still sit in front of its link and take care of the in-app browser step it does not cover.

Three of those five rows do not need a measurement platform at all, which is the opposite of the impression Google’s list gives — and the migration that turns into a procurement exercise is almost always one that skipped this table. Finding out which row you are in starts with the inventory, because most teams have links in more than one row and only remember the loudest.

If you only need the routing half

Here is what carries over from Dynamic Links and what does not, so you can check it against your own usage before committing to anything.

Two rows in the table above need their footnotes read rather than skimmed: campaign parameters carry over only partly, and a domain you own carries over only once you configure it yourself.

Campaign parameters. Apple’s App Store reads a campaign token (ct) alongside a provider token (pt), and without the provider token the campaign never appears in App Store Connect at all. Google Play reads UTM values inside a referrer parameter. An AppIn link composes the Apple ct and the Play referrer — carrying utm_source and utm_campaign — on every click, from the campaign on the link and the source it can see. The Apple provider token is yours: you paste your pt into the link once and it is sent with every click after that. We cannot invent it, and a tool that claimed to would be sending Apple a number that means nothing.

Your own domain. Dynamic Links let you serve short links from a domain you control, and that carries over: point a subdomain of your own at us with a CNAME, add the TXT record we show you, and your links are served from your address. There are two things to prove and they clear separately — that the domain is yours, and that its certificate has been issued — so the screen tells you which of the two is still outstanding rather than one undifferentiated “pending”. Pro carries three such domains; the smaller plans serve links from ours. After one shutdown, publishing on an address you control is worth the ten minutes it costs.

The last two rows are the deliberate limit, and they are one capability rather than two: deferred deep linking is the trick where a payload survives an install so a brand-new user lands on a particular screen, and the only way to carry a payload across an install is install attribution. Both need an SDK inside your app, which is exactly what this kind of tool exists to avoid. They are not mutually exclusive, though — an AppIn link can point at a measurement link, so you can have both without choosing.

How to migrate

1. Inventory the dead links. Search your repositories, store listings, email templates, ad accounts and social profiles for page.link. Everything you find is returning a 404 right now.
2. Mark the ones that needed deferred deep linking. Typically invite and referral flows, where a new install has to land on a specific screen. Those belong on a measurement platform, not here.
3. Recreate the rest. Paste the App Store or Play URL. On a paid plan you can also set a desktop destination if you need one; free links still route phones and show a QR for computers.
4. Republish everywhere. Bio links, README badges, ad destinations, email footers, support macros. This is the slow part, and it is the only part that actually restores traffic.

One failure worth fixing while you are in there

You are about to edit every link you own, so it is a cheap moment to fix something Dynamic Links never covered.

A store link opened inside Instagram’s in-app browser often dies on a blank page. The link is not rejected and it is not malformed — the hand-off from the in-app browser to the App Store fails, silently, and the visitor leaves. A page.link URL was an HTTPS link like any other, so it met the same wall; if your bio link underperformed before the shutdown, this is a likely reason and it was never a Firebase problem.

An AppIn link leaves the in-app browser before the store hand-off: the page asks the host app to reopen it in the phone’s real browser, and the hand-off then happens where it works. It runs on load, so the visitor has nothing to tap. Where there is no in-app browser to leave, the link opens the store the ordinary way.

How the in-app browser failure actually works