Firebase Dynamic Links referral links: how to migrate without losing referrers

Referral programmes were one of the most common uses of Firebase Dynamic Links. A user taps "Invite friends", the app builds a yourapp.page.link address with their code in it, a friend taps it, installs the app, and the inviter gets their reward. It was free and mostly worked.

Firebase Dynamic Links shut down on 25 August 2025. Referral links are hit harder than most links, because they depend on three things at once: making a new link for each person, getting the friend through an install, and telling your app who invited them. This post covers what breaks, and how to move without losing the credit.

The short answer

• Your share button may already be broken. If the app asked Firebase to make a short link for each invite, that request no longer works. Check what your app shares today.
• Put the referrer in a link on your own domain, for example link.yourapp.com/invite/ABC123. One rule can handle every code, so you don't need a link per person.
• Carry the referrer through the install. Android can do this exactly, with the Play Install Referrer. iOS has no equivalent, so it's either a short-lived match or a clipboard hand-off.
• Keep reading the old links in your app, and keep a "have an invite code?" field as a backup for the links you can't move.
• Only pay rewards on credit you trust. An estimated iOS match is fine for showing a welcome screen, not for paying money.

How Firebase referral links usually worked

Most apps followed the same pattern:

1. The app built a long Dynamic Link whose link parameter carried the code, such as https://yourapp.com/invite?code=ABC123, and asked Firebase to shorten it to yourapp.page.link/xyz.
2. A friend tapped it. If they had the app, it opened, and the Dynamic Links SDK handed your code the original link.
3. If they didn't, they went to the store. On first launch, the SDK tried to recover the link: on Android through Google Play, on iOS through Firebase's preview page and the clipboard.
4. Your app read code=ABC123, recorded the invite, and rewarded the inviter when the friend signed up.

Every step ran on Google's servers and Google's SDK.

What breaks after the shutdown

• Making new links. Apps that created short links through the Dynamic Links API now get an error. Depending on how the share code handles it, people may share a long page.link address, a plain web link, or nothing.
• Old links in the wild. Many page.link links still answer for now, but on iPhone they show Google's "Open in app?" page instead of opening the app (what that page is), and Google can stop serving them at any time.
• Credit after an install. If your new app version drops the Dynamic Links SDK, nothing reads the link on first launch. The friend installs, opens the app on the home screen, and the inviter is never credited.

That last one is the expensive one. Referral programmes usually run on a small number of people who invite a lot, and they notice quickly when their invites stop counting.

Step 1: Find everything that makes or reads referral links

Before you change anything, list:

• every place the app creates an invite link (share sheet, "invite friends" screen, post-purchase prompt), and what the link contains;
• every place the app reads one (cold start, a link while the app is open, first launch after install);
• your backend's rule for crediting and rewarding, and what it trusts (the code in the link? a code typed in?);
• how many people are on app versions that still create page.link links. They will keep sharing those until they update.

The Dynamic Link decoder shows what each parameter in one of your long links does, so you know what the new link has to carry.

Step 2: Choose a link format on your own domain

Use a subdomain you control, such as link.yourapp.com, so you never have to do this again. Two common formats:

• Code in the path: link.yourapp.com/invite/ABC123. One rule passes everything after /invite/ to the app, so there's nothing to create per person, and the address is short and readable.
• Code in the query: link.yourapp.com/invite?ref=ABC123. Just as good, and easy to add to any existing link.

Use an opaque code, not an email address or a name. It appears in the address, and people paste these links into public places.

The domain has to serve an apple-app-site-association file and an assetlinks.json file naming your app, and the app has to list the domain, or phones will open the browser instead of the app. Our Universal Links checklist and App Links checklist cover the details.

Step 3: Carry the referrer through an install

This is the part Firebase did for you, and the part that decides whether referrers get credited.

Android. When the link sends someone to Google Play, add a referrer to the Play URL. After the install, your app reads it once with the Play Install Referrer API. It is exact: the value you put in the link is the value the app gets.

iOS. The App Store passes nothing through an install, so there are two options:

• Matching. The link service records the tap, and on first launch the app asks "did someone just tap one of my links on this device?". The answer is a good guess, not a certainty: it can go wrong on shared networks or with VPNs and iCloud Private Relay. Our deferred deep linking explainer goes through how it works.
• Clipboard hand-off. The page before the App Store copies a token, and the app reads it on first launch. It is exact, but since iOS 16 reading the clipboard shows a paste prompt, so most apps have the person tap a paste button.

A sensible rule: use any match to personalise the first screen ("Priya invited you, here's your free month"), but only pay a reward on an exact match, or once the new account checks out in your own records.

Step 4: Update the app to read both

Ship one version that:

• reads the new links: on a cold start, while running, and on first launch after an install;
• still reads old page.link links that open the app, and pulls the code out of their link parameter;
• shows an "Have an invite code?" field during sign-up. Codes are already in people's messages and screenshots, and this catches every link you couldn't move.

Then switch the share button to the new links. Do it after the update is out, because the new domain only opens the app in builds that list it.

Step 5: Decide what happens to old links

You can't redirect or edit page.link links: the domain belongs to Google. While Google keeps answering, tapping one may still open your app (on Android, and from some places on iPhone) or reach the store. When it stops, those links fail. The invite code field is your safety net.

Reprint anything you control: QR codes on packaging, links in onboarding emails, pinned posts.

Test it like a real invite

Use two phones, and test with the app installed and not installed. Send the invite through WhatsApp, Instagram and email, because each one opens links differently (why Instagram is different). For each case, check that the right person was credited, and that the reward rule only fired when you expected it to.

Where DL2App fits

DL2App was built as a replacement for Dynamic Links, and referral links are a first-class feature:

• Any link can carry a referrer. Add ?dl2_ref=user_8812 to a link and every tap, install and in-app event that follows is credited to that id, or make a personal invite link for someone in the dashboard.
• Personal links from the app. With the React Native SDK, DL2.createLink({ path: "/invite", referrer: currentUser.id }) returns a short link to share.
• The app is told who invited. The link your app receives has referrer set, and isFirstOpen says it's a new install. Each install shows whether it was matched exactly (Play install referrer or clipboard) or estimated.
• A Referrals page lists each person's clicks, new installs, events and revenue, and you can pause crediting someone without breaking their links.
• Import from Firebase moves your existing links across with their paths.

We credit, we don't pay: rewards and fraud rules stay in your backend. The React Native SDK (including Expo) and the web SDK support referrers today. The native iOS, Android and Flutter SDKs are built and in final testing. See the referral docs and pricing.

Questions people ask

Do Firebase Dynamic Links referral links still work? Some still redirect, but Google shut the service down on 25 August 2025 and can stop serving them at any time. New links can't be created, and on iPhone people see a Google page instead of the app.

How do I keep crediting referrers after an install without Firebase? On Android, pass the referrer through Google Play's install referrer, which is exact. On iOS, use either a match made on first launch or a clipboard hand-off. Only pay rewards on exact matches or verified sign-ups.

Can I redirect my old page.link referral links to a new domain? No. page.link belongs to Google, so you can't change where those links go. Keep reading them in your app while they work, and add an invite code field as a fallback.

Do I need a separate link for every user? No. Put the user's code in the path or query of one link format, and have one rule pass it to the app.

What should be in a referral link? An opaque id or code that your backend can look up. Don't put email addresses, names or reward amounts in the link.