Firebase Dynamic Links replacement: what to use after the August 2025 shutdown

the situation

You shipped Firebase Dynamic Links three years ago. It worked. Then on August 25th, 2025, Google's hosted FDL service stopped resolving. Any link of the form yourapp.page.link/xyz now returns a 404 from goo.gl or sits in a permanent loading state on your domain's *.page.link subdomain. Your install attribution is dark. Your onboarding flow is broken on cold installs. Your support inbox is filling with screenshots of blank pages.

This guide is the post-mortem and the migration map. It assumes you're a mobile engineer or a tech lead at a product org that depended on FDL for deferred deep linking, install attribution, or cross-platform link routing.

The consumer-side manifestation of the same class of problem — links that fail in social-app webviews — lives on the thesis page. This guide is the engineering counterpart.

what FDL actually did

Three jobs, often confused as one:

1. Universal short link routing. A single *.page.link URL that, when tapped, opened the iOS app if installed, the Android app if installed, or a fallback web URL otherwise. Underneath: an Apple App Site Association file at the FDL domain plus a Digital Asset Links file plus a server-side branching service that read User-Agent and decided whether to redirect or serve the universal-link metadata.

2. Deferred deep linking. If the app wasn't installed, the link routed to the store. After install, the SDK retrieved the original link parameters on first launch and routed the user to the originally-intended destination inside the app. The state was carried via fingerprint matching (IP + UA + screen size) for ~30 minutes after store install, then dropped.

3. Custom URL parameters with preview metadata. OG tags, social-share previews, and arbitrary developer-defined parameters bundled into the link payload.

FDL was the only Google-hosted product that bundled all three. That's why removing it broke so much.

why Google killed it

Two reasons stated in the deprecation notice, one structural:

• Apple's Universal Links and Android's App Links matured. The cross-platform routing job is now natively solvable without a third-party service.
• The deferred-deep-linking job is harder, less common, and increasingly hostile to platform privacy posture. Apple's App Tracking Transparency and IDFA deprecation broke fingerprint matching. Android's Play Install Referrer provides a clean alternative for the Play Store path.
• Structurally: FDL was a near-free product with high operational cost, weak monetization tie-in to other Firebase services, and a shrinking platform-policy window. Killing it was straightforward inside Google.

The shutdown was announced October 2023, the resolution window held until August 2025, and the service is now offline.

the four replacement architectures

There is no single drop-in. The replacement depends on which of FDL's three jobs you actually used.

Pick by job, not by brand familiarity.

option 1 — Universal Links + App Links (the platform-native path)

If you only used FDL for routing — no deferred attribution, no install funnel — the native iOS/Android primitives are now mature enough to replace it directly.

iOS Universal Links: an HTTPS URL associated with your app via an Apple App Site Association file served from your domain. When the user taps the link, iOS checks the AASA file, matches paths, and either opens your app or falls back to Safari. Detailed setup walkthrough. The AASA file format specifics: /guides/aasa-file-explained.

Android App Links: the same pattern with an assetlinks.json file. Detailed setup walkthrough. File format: /guides/assetlinks-json-explained.

The comparison of the three deep-link primitives (universal, deep, app) is here: /guides/universal-link-vs-deep-link-vs-app-link.

Cost: zero ongoing infrastructure cost. You host two static files. You handle preview metadata yourself via OG tags. You don't get deferred deep linking — first-launch routing is on you.

Best for: apps with established install funnels (App Store featuring, paid acquisition, organic search) where the original-link-on-first-launch use case is rare.

option 2 — branded smart-link SaaS

Branch.io, AppsFlyer OneLink, and Adjust deep links are the established replacements. All three add deferred deep linking, attribution analytics, and preview metadata on top of Universal Links + App Links.

Cost structure is per-MAU or per-event, ranging from a few hundred dollars per month for small apps to five-figures monthly for high-MAU consumer apps. SDK integration is required — iOS framework plus Android Gradle dependency plus init code in AppDelegate / Application.

Alternative pages: /guides/branch-io-alternative, /guides/appsflyer-onelink-alternative, /guides/adjust-deep-links-alternative.

Best for: apps with paid-acquisition budgets where attribution accuracy directly drives spend allocation. The SDK overhead is justified by the data.

option 3 — build-your-own server

Host a routing service at yourdomain.com/l/:slug. Serve the AASA and assetlinks.json files from yourdomain.com/.well-known/. Implement the deferred-deep-link state machine yourself:

• Android: register a Play Install Referrer handler. Pack the original link payload into the referrer string. Read it on first launch.
• iOS: use SKAdNetwork for attribution; for first-launch routing, the only reliable method now is a server-set cookie/clipboard handoff prior to redirect, which Apple has progressively restricted.

This is what Branch and AppsFlyer give you out of the box. Building it yourself is reasonable when you have a platform team and don't want to ship a third-party SDK. Most teams who try this underestimate the iOS-edge-case maintenance load.

Best for: product orgs with infrastructure teams and a hard requirement on no-third-party-code-in-app.

option 4 — no-SDK hosted link infrastructure

This is the category linkboo occupies. The use case: you want short branded links that resolve correctly across browsers and apps, render social-preview metadata, and survive in-app browser hostility — but you don't operate a mobile app at all, or your mobile app doesn't need deferred deep linking.

The category exists because most "smart link" users aren't FDL users in the first place. They're creators, agencies, and product-led growth teams who want links that work. SaaS in this category — including legacy players like Linkfire and Songlink for music — handles routing, preview metadata, and in-app browser escape, without an SDK requirement.

For technical buyers evaluating linkboo specifically: the /api and /docs routes carry the contract surface. There is no mobile SDK because there is no mobile app integration — link.boo links resolve in the system browser by design, including escape flows for hostile webviews like the TikTok and Instagram in-app browsers.

Best for: non-app use cases — bio links, music releases, campaign tracking, creator funnels — where the FDL feature set was overkill in the first place.

decision matrix

The single biggest failure mode in 2025: teams replacing FDL with another full smart-link SaaS when they only used the routing job. Pay for Branch when you actually use Branch's attribution. Otherwise, the native primitives are sufficient and free.

migration sequence

If you're migrating off FDL today, the order matters:

1. Audit which job you used. Read your own FDL initialization code. If you never read getDynamicLink() on first launch, you weren't using deferred deep linking. Don't pay for it in the replacement.
2. Stand up AASA + assetlinks.json on your own domain. Test universal-link routing in isolation before changing anything else. Full walkthrough: /guides/firebase-dynamic-links-migration.
3. Redirect FDL URLs. Map your *.page.link/xyz URLs to yourdomain.com/l/xyz server-side. FDL no longer resolves, but inbound traffic referencing the old URLs in pasted content, screenshots, and embedded media will keep arriving for months. Capture it.
4. If using a SaaS replacement, integrate the SDK. Test the deferred deep link path end-to-end with a fresh install on a real device. Simulators don't reproduce the install-referrer edge cases.
5. Decommission FDL config. Remove the Firebase iOS framework's dynamic-links dependency, the Android firebase-dynamic-links Gradle dependency, and any FDL-specific code in AppDelegate.swift / Application.kt. The deprecation will not auto-remove these for you.

Most teams complete the migration in two to four weeks, with the long tail being install-attribution accuracy validation for paid-marketing teams.

deferred deep linking, specifically

FDL's deferred deep linking is the job hardest to replace cleanly. Background: /guides/deferred-deep-linking-explained.

In short: the iOS path no longer supports fingerprint matching at acceptable accuracy post-ATT. The Android path via Play Install Referrer works well. If your funnel weighting splits ~50/50 between iOS and Android, you should expect ~50% accuracy loss on iOS first-launch routing regardless of which SaaS you pick. Vendors that claim otherwise are using techniques that violate Apple guidelines and risk app rejection.

The honest answer: deferred deep linking on iOS in 2025 is a degraded product. Plan your install funnel accordingly.

what about web-only flows

If your "deep link" is actually a web destination — a bio link, a checkout URL, a creator profile — none of the above applies. The relevant failure is in-app browser cookie isolation, not deferred attribution. See /guides/in-app-browser-cookies-explained for the engineering breakdown, and the escape flow for the consumer-side fix.

This is the use case linkboo serves directly. No SDK, no install attribution, no app required. Short branded links that escape hostile webviews into the system browser, with social-preview metadata served from the link itself.

further dev reading

• iOS Universal Links setup: /guides/ios-universal-links-setup
• Android App Links setup: /guides/android-app-links-setup
• AASA file format: /guides/aasa-file-explained
• assetlinks.json format: /guides/assetlinks-json-explained
• Android intent URLs: /guides/intent-url-android
• Open-in-app-from-web pattern: /guides/open-in-app-from-web
• Universal Links vs deep links: /guides/universal-links-vs-deep-links

If you've finished the migration and are evaluating no-SDK link infrastructure for the non-app side of your stack — bio links, campaign tracking, creator funnels — the link.boo/api and link.boo/docs routes are the contract surface for linkboo.

references

• Firebase Dynamic Links deprecation announcement, October 2023
• Firebase Dynamic Links FAQ, shutdown August 25, 2025
• Apple App Site Association documentation
• Google Digital Asset Links documentation
• Play Install Referrer documentation
• Apple App Tracking Transparency framework documentation