How to replace Firebase Dynamic Links

Updated October 8, 2026

Firebase Dynamic Links stopped working on 25 August 2025. Not every Dynamic Link did the same job, so the replacement depends on what each one was for. This is a plan for sorting them and moving each kind.

For a side-by-side table of what SetLinks replaces and what it does not, see the Firebase Dynamic Links comparison. This guide is the practical part: how to find every link and move it.

Step 1: find every Dynamic Link you still use

Old links hide in more places than the Firebase console. Search the code and the material you have published:

# Links and SDK calls in your repositories
grep -rn 'page.link\|FirebaseDynamicLinks\|firebase-dynamic-links' .

# Custom domains you set up for Dynamic Links
grep -rn 'dynamicLinksDomain\|DynamicLinks' .

• Printed material: QR codes on packaging, posters, flyers and business cards.
• Emails: onboarding, password reset and referral templates.
• Profiles and listings: social bios, your website, partner pages.
• Ads that are still running, and old campaigns people may still click.

Step 2: sort them by what they did

Each Dynamic Link did one of three jobs. Write the job next to every link you found.

• Store links: send iPhone users to the App Store and Android users to Google Play, and desktop users to a website. Most QR codes and marketing links were this.
• Links into the app: open a screen in the app when it is installed — a product, an invite, a reset form.
• Deferred deep links: carry the link through an install, so the app opens on that screen the first time it starts.

What the old link parameters become

A long Dynamic Link carried its settings as parameters. Most have a direct counterpart in a SetLinks link’s destinations:

• isi (App Store ID) → the App Store address, https://apps.apple.com/app/id plus the number.
• apn (Android package) → the Google Play address, https://play.google.com/store/apps/details?id= plus the package.
• ifl and afl (where iOS and Android go when the app is not installed) → the iPhone or Android destination itself. It can be any web address, not only a store.
• ofl (other platforms) → the address for computers, or the fallback.
• link (the deep link inside the app) → the link’s own path, which an installed app receives through universal links or App Links — see step 4.
• st, sd, si (social preview title, description and image) → no counterpart. SetLinks does not set preview text; apps that show a preview show the one of the page the link leads to.

Step 3: replace the store links

1. Create a SetLinks link per Dynamic Link, with the same App Store, Google Play and fallback addresses. Add AppGallery or RuStore if your app is there — Dynamic Links never supported them.
2. Many links? Create them through the REST API from a script instead of by hand. The API is on plans that include it, listed on the pricing page.
3. Swap the addresses in emails, bios, your site and running ads.
4. Reprint the QR codes. This is the one reprint you pay for: a SetLinks code keeps its address when the destinations change, so later changes never need one.

Links on *.page.link belonged to Google, and nobody can make them work again. If you used a domain of your own for Dynamic Links — links.example.com — you still control its DNS. Connect that subdomain to SetLinks as a custom domain and recreate the paths you printed, and the old addresses work again. SetLinks addresses are lowercase letters, digits and hyphens, at least three characters, so only paths of that shape can be recreated as they were.

Step 4: replace links into the app

Opening an installed app from a link is a platform feature now: Universal Links on iOS, App Links on Android. They need no SDK — a file on the link’s domain names your app, and the app declares the domain. SetLinks publishes those files for your links. On iPhone this works on setlinks.io and on your own domain; on Android only on your own domain, because on a shared domain one app could claim other people’s links. The universal links and App Links guide has the full setup.

In the app, remove the Dynamic Links SDK and handle the incoming URL with the platform API: onOpenURL or scene(_:continue:) on iOS, the intent data in your activity on Android. The path of the URL is the link’s address, so the app can route on it.

Step 5: decide about deferred deep links

If a link must survive the install — a referral code, an invite to a specific team — you need an attribution SDK in the app. SetLinks has no SDK and does not do this. Branch, AppsFlyer and Adjust do; so can your own backend if you are willing to match installs yourself. Be honest about how many links need it: in most apps it is a handful, while the hundreds of store links need nothing in the app.

Step 6: check analytics and clean up

• Compare click counts on the new links with what Firebase showed. SetLinks counts clicks and QR scans by day, platform, country and source, and leaves link-preview bots out.
• Turn on store campaign attribution where your plan includes it: installs from each link then show up in App Store Connect and Google Play Console under the link’s address, such as cafe-table.
• Remove the Firebase Dynamic Links dependency from the app and the domain configuration from Firebase Hosting.