When did Firebase Dynamic Links shut down?

Firebase Dynamic Links shut down on August 25, 2025. After that date all FDL links stopped resolving and developers can no longer create new ones. Google announced the deprecation in 2023 with no first-party replacement.

Can Universal Links and App Links fully replace Firebase Dynamic Links?

No. Native Universal Links and App Links open an app that is already installed, but they do not carry a destination through a fresh install (deferred deep linking) and provide no install attribution. Those were exactly the features FDL layered on top.

What is the best replacement for Firebase Dynamic Links?

For direct opens, use native Universal Links and App Links. If you need deferred deep linking and attribution across iOS and Android, add an MMP such as AppsFlyer OneLink or Branch. On Android alone, the Google Play Install Referrer API can pass campaign and deep-link data through an install.

How do I migrate an Expo or React Native app off FDL?

Audit every live FDL link, configure native Universal Links and App Links and handle them with the React Native or Expo Linking API, decide whether deferred deep linking is required, add an MMP SDK if it is, then replace the links everywhere and retest the install-then-route path on both platforms.

Firebase Dynamic Links Is Gone — What to Use for App Links Now

Jun 19, 2026

Firebase Dynamic Links (FDL) shut down on August 25, 2025. As of that date Google stopped resolving every FDL short link — both page.link subdomains and links on custom domains — and disabled the creation of new ones (Dynamic Links Deprecation FAQ, Firebase). Any app that relied on FDL for deep links, deferred deep linking, or install attribution now has dead links and needs a replacement. The modern stack is native iOS Universal Links + Android App Links for opening an installed app, plus a third-party deep-link or mobile measurement partner (MMP) like AppsFlyer OneLink or Branch for deferred deep linking and attribution. Google announced the deprecation in 2023 and shipped no first-party successor, so the migration is on the app developer.

What Firebase Dynamic Links actually did

FDL was a single short link that behaved differently depending on where it was opened. If the app was installed, the link opened directly to a specific screen. If the app was not installed, FDL sent the user to the App Store or Play Store, and then — after the install — routed them to the exact in-app destination the original link pointed at. That last part is deferred deep linking: the destination survives a fresh install and a trip through the store (Dynamic Links Deprecation FAQ, Firebase).

That single capability is what made FDL worth using. Plain URLs lose all context the moment a user bounces to the store and comes back. FDL carried the intent across that gap, picked the right platform automatically, and did it for free.

Why "just use Universal Links and App Links" is not a full replacement

The first advice most developers hear is to switch to Apple's Universal Links and Google's Android App Links. Both are the right foundation, and both are free OS features that map an HTTPS URL to a screen inside an installed app. For a user who already has the app, they open it directly and skip the browser entirely.

The catch is what they do not do. Native app links only fire when the app is already installed. There is no built-in mechanism to carry a destination through a new install — tap a Universal Link without the app and iOS opens the URL in Safari, not the store. They also carry no attribution: nothing tells the marketing team which campaign, channel, or creative drove the install. Deferred deep linking and attribution are precisely the two things FDL layered on top of native linking, and they are the two things native links still lack.

The replacement options, compared honestly

There is no single drop-in for FDL. The right answer depends on whether deferred deep linking and attribution matter to the app.

Native Universal Links (iOS) and App Links (Android) handle the direct-open case. If the only requirement is "tap a link, open the installed app to the right screen," these are sufficient and free. They are also the layer every other option builds on, so set them up regardless.

Google Play Install Referrer (Android) passes campaign and custom data through a new install on Android. The Play Store attaches a referrer string to the install, and the Play Install Referrer API reads it back on first launch — enough to reconstruct a deferred deep link or campaign source on Android without a third party. iOS has no public equivalent, which is the structural reason a cross-platform app usually still needs an MMP.

A deep-link or MMP platform — AppsFlyer OneLink or Branch. These rebuild what FDL did and add the attribution it never had. OneLink and Branch both provide one cross-platform link that does deferred deep linking on iOS and Android, plus campaign-level install attribution (AppsFlyer deep linking docs; Branch deep linking docs). AppsFlyer published explicit FDL migration guidance positioning OneLink as the replacement (AppsFlyer FDL deprecation guide). This is the most complete option, and the most involved to integrate, because it adds an SDK and a vendor relationship.

One thing none of these change: on iOS, privacy-safe install attribution still runs through SKAdNetwork and App Tracking Transparency (Apple SKAdNetwork docs). An MMP makes deferred deep linking work and stitches the campaign data together, but Apple still gates the underlying iOS attribution signal — see why SKAdNetwork makes iOS install data coarse and delayed.

A migration checklist for an Expo or React Native app

For a vibecoder with an Expo or React Native app, the migration breaks into a foundation step and an optional attribution step.

Audit every live FDL link. Anything still pointing at *.page.link or an FDL custom domain is already returning errors. List where they live: emails, ads, share sheets, QR codes, push payloads.
Stand up native links first. Configure Universal Links on iOS (Associated Domains entitlement plus an apple-app-site-association file) and App Links on Android (a Digital Asset Links file plus verified intent filters). In Expo, set the scheme and associatedDomains / intentFilters in app.json and handle incoming URLs with the React Native Linking API or Expo Linking.
Decide whether deferred deep linking is required. If users frequently install from a link and must land on a specific screen, native links alone will not cover it. On Android the Play Install Referrer can carry the data; for cross-platform parity, add an MMP.
If using an MMP, install it once and keep one event taxonomy. Add the AppsFlyer or Branch SDK, route links through OneLink or a Branch link, and verify deferred deep linking on a clean device.
Replace the links in every surface and retest the install-then-route path end to end on both platforms.

Where VibeTraker fits

VibeTraker documents AppsFlyer as its MMP for mobile apps. It generates the install and event contract — including the react-native-appsflyer SDK setup and a stable owned-event taxonomy where canonical events like signup_completed, trial_started, and purchase_completed map to AppsFlyer's af_complete_registration, af_start_trial, and af_purchase (connect AppsFlyer guide). That keeps one consistent event vocabulary across the deep-link platform replacing FDL and the rest of the stack. To be precise about scope: VibeTraker sets up the install and contract and maintains that taxonomy — it does not pull AppsFlyer dashboard reports through a Data API.

The honest takeaway: FDL is gone, native app links are the free foundation but stop at the install boundary, and deferred deep linking plus attribution now require either Android's Install Referrer or a dedicated MMP. For the trade-offs between Firebase's free SDK and a paid MMP, see Firebase vs AppsFlyer, and for why plain links never tracked installs in the first place, why UTM links don't track app installs.