Deep Linking in 2026: What Replaced Firebase Dynamic Links and How to Set It Up

A deep link is a link that opens a specific screen inside a mobile app, not just the app's front door. Firebase Dynamic Links, the free Google service many apps used for this, shut down on August 25, 2025. In 2026 you have two real choices. Use Universal Links and Android App Links on your own domain for free, or pay a provider such as Branch, AppsFlyer, Adjust or Airbridge if you need links that survive an app install.

This guide replaces the older deep linking explainers and vendor docs that no longer load. Every date and price below comes from the vendor's own page, checked on October 17, 2026.

What deep linking means, in plain words

• Deep link. A link that goes to a place inside an app, such as a product, an invoice or an invite. A normal link opens the app's home screen at best.
• Universal Links (iOS). Apple's version. You tap a normal https link, and iOS opens your app if it is installed. If not, the link opens in the browser. Apple checks a file on your website, called apple-app-site-association, to confirm the link belongs to your app.
• Android App Links. Google's version. Same idea. Android checks a file called assetlinks.json on your website.
• Deferred deep link. A link that works even when the app is not installed yet. The user taps, installs the app from the store, and lands on the right screen on first open. This is what Dynamic Links did well, and it is the part plain Universal Links and App Links do not do.
• Click analytics. Counts of who clicked which link. Dynamic Links had some. Google's migration guide offers no replacement for it.

Marketers mostly care about the last two. Developers mostly care about the first three.

What happened to Firebase Dynamic Links

Google's own FAQ says Dynamic Links shut down on August 25, 2025. This is what that means for old links:

• Every clicked link returns an HTTP 404 to the user.
• Short link creation and link stats API calls return 400 or 403 errors.
• Existing .page.link domains cannot be kept or transferred. Domain and link data is marked for deletion on the shutdown date.
• The SDKs will not crash your app by themselves, but your code has to handle the new responses. For example, on iOS, short link creation now returns a 403, and first-open attribution returns empty data.
• Email link sign-in, password reset and email verification on mobile needed updated SDKs. Google has separate guides for iOS and Android.

Google's own advice, in its FAQ:

1. If you need full feature parity, use a third-party provider. The FAQ names Adjust, Airbridge, AppsFlyer, Bitly, Branch, Kochava and Singular, and says Google has not vetted them.
2. If you only need to open an installed app, use Universal Links and App Links. The official migration guide covers this path.
3. If you no longer need the links, review them, delete the URL prefixes and remove the SDK.
4. Export your link metadata, and if you keep a custom domain, update your rewrite rules in firebase.json.

The migration guide is honest about the gap. Universal Links and App Links do not send users to the app store, and do not carry the journey through a first install. For iOS it recommends Smart App Banners as the closest substitute.

What to use now

Two cautions on that table. First, "deferred" and "analytics" here are what these vendors sell in general. Test the exact features on the plan you are quoted. Second, several of these tools are attribution platforms first and link tools second. If you only need links, that can be a lot of product to buy.

How to choose

1. Your users already have the app, and links come from emails, your website or in-app shares. Use plain Universal Links and App Links. It is free, it is the platform's own mechanism, and no vendor can shut it down.
2. You run paid ads that send new users to the app store. You need deferred deep linking and attribution. Pick a provider, and ask for a quote that matches your install volume.
3. You are a small team that wants links and little else. Look at the lowest published tier first (Airbridge Core or AppsFlyer Zero; Zero covers basic routing only), and read what the free or entry plan actually excludes before you commit.
4. You want first-open routing without a vendor. Combine Universal Links, a Smart App Banner on iOS, and a small server route that remembers the intended screen. It takes some build time, but you own it.
5. You have old Dynamic Links printed or published. Links on a .page.link domain are gone for good, because Google will not let anyone keep those domains. If your links used your own custom domain, point that domain at your website and redirect the old paths to the right pages. Either way, publish new links on your own domain.

If you are unsure, start with option 1. You can add a provider later without changing your domain files.

Set up Universal Links and App Links on your own domain

Use a domain you control, and use the same domain in every step. Apple and Google both want the files served over HTTPS with no redirects.

1. Pick the links. Decide which paths open the app, for example /invite/* or /invoice/*. Keep the list short.
2. Create the iOS file. Host it at https://yourdomain.com/.well-known/apple-app-site-association. The name has no .json extension. Apple's docs say to host it over HTTPS with a valid certificate and no redirects. A minimal version looks like this:

{
  "applinks": {
    "details": [
      {
        "appIDs": ["TEAMID.com.example.app"],
        "components": [{ "/": "/invite/*" }]
      }
    ]
  }
}

3. Add the iOS entitlement. In Xcode, open Signing & Capabilities, add Associated Domains, and add applinks:yourdomain.com. Use the bare domain, with no path and no trailing slash. Personal development teams cannot use this capability (per Flutter's setup guide).
4. Create the Android file. Host it at https://yourdomain.com/.well-known/assetlinks.json, with content type application/json and no redirects:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.app",
    "sha256_cert_fingerprints": ["AA:BB:...:FF"]
  }
}]

If you use Google Play App Signing, copy the fingerprint from the Play Console (Release, Setup, App signing). The one from your local keystore will usually not match what is on users' phones.

5. Add the Android intent filter. In AndroidManifest.xml, add an intent-filter with android:autoVerify="true", the VIEW action, the DEFAULT and BROWSABLE categories, and <data android:scheme="https" android:host="yourdomain.com" />.
6. Handle the link in your app. Read the incoming URL and route to the right screen. Do this for both a cold start and an app that is already running.
7. Test before you ship.
   • iOS: Apple fetches your file through its own CDN. Per Apple's docs, the CDN asks for your file within 24 hours, and devices re-check about once a week. You can see what Apple has cached at https://app-site-association.cdn-apple.com/a/v1/yourdomain.com. For a private dev server, Apple's alternate mode bypasses the CDN. Then tap a link from the Notes app on a real device.
   • Android: run adb shell pm get-app-links com.example.app and look for verified next to your domain. Google's Statement List Generator and Tester can generate and check the file.
   • We know of no Apple-run web validator for the apple-app-site-association file today, so on iOS rely on the CDN URL above and a real device.

The usual failures are a redirect in front of the file (including www to non-www), the wrong signing fingerprint, a Team ID typo, and testing before Apple's CDN has caught up.

Flutter specifics

Flutter has official guides for both platforms: set up universal links and set up app links. Per those pages, Flutter 3.27 and later turn deep linking on by default. Older versions need FlutterDeepLinkingEnabled set to YES in Info.plist and flutter_deeplinking_enabled set to true in AndroidManifest.xml.

Two ways to receive links:

• go_router. Flutter's built-in handling feeds incoming links to the Router. go_router (version 18.1.0 on pub.dev today) is a declarative router built on that system and lists deep linking as a feature. Define your paths as routes, and an incoming link lands on the matching screen.
• app_links. The app_links package (7.2.2 today) handles Android App Links, iOS Universal Links and custom schemes. You subscribe to AppLinks().uriLinkStream, which delivers both the first link and later ones. Per Flutter's docs, if you use a plugin like this, set the deep linking flag to false so Flutter's own handler does not conflict.

Flutter DevTools also has a Deep Links validator. It checks website configuration and manifest files, and works for Android and iOS from Flutter 3.27.

Need a hand?

App369 is Simon Dziak's studio. He builds and runs Workspace369, a production Flutter and Firebase SaaS.

• Links open the wrong screen, or the app never opens from a link: the App Fix Ticket diagnoses one issue for $450 and fixes it for $1,200, both fixed price (the $450 is credited toward the fix).
• Connecting a link provider, your backend and a CRM or Stripe: API Integration, $1,200 fixed price, 5 business days.