Migrating Off Firebase Dynamic Links and Custom Schemes

Where Dynamic Links stand

Firebase's deprecation FAQ said that "your new and existing links will continue to work until the Dynamic Links service is shut down on August 25th, 2025." After the shutdown, clicked links return an HTTP 404 status, and Dynamic Links domains and link metadata were marked for deletion under Firebase's data retention policy. The FAQ page was updated again in October 2026; if your team still has Dynamic Links in a console, check their status there before planning.

For app deep linking, the FAQ points to the platforms' own features, App Links and universal links, which it calls "platform-supported ways for developers to provide deep-linking experiences." A related service has also changed: Firebase now says Firebase App Indexing is "no longer the recommended way of indexing content for display as suggested results," and recommends universal links and App Links for linking users to app content.

Step 1: find every old link

Dead links hide in places nobody reviews. List each source and the destination the old link was meant to reach:

• Email and push templates, including old automated campaigns still running.
• QR codes on printed material and venue signage.
• Partner and media pages you cannot edit quickly.
• Help center articles, in-app messages and social profiles.
• Saved links inside the app itself, such as share buttons.

Step 2: map each link to an https route

Give every destination a stable https address on your own domain, with a web page that works without the app. A Dynamic Link to an event becomes https://www.example.com/events/123; a Dynamic Link to the app's home becomes your site's home or a relevant landing page. Keep the map in a spreadsheet so you can test each row.

Step 3: verify the domain for both apps

Publish assetlinks.json and the apple-app-site-association file on each host the new links use, add the matching intent filters and Associated Domains entries, and confirm verification on devices. The file rules are in the assetlinks.json guide and the Apple App Site Association (AASA) guide. Timing matters: Apple's CDN requests the file within 24 hours and devices check about weekly, and Android 15 and later can take up to seven days to pick up changes.

Step 4: retire custom-scheme links

If your app uses custom schemes for push notifications or campaigns, move those to https routes as well. Keep the scheme handler in the app while older versions are in use, but treat every value it receives as untrusted: Android's guidance is to validate all incoming deep link data "against a predefined allowlist of expected values."

Step 5: decide what happens after an install

Dynamic Links offered to carry a destination through an install. Without it, Android apps can read the Play Install Referrer on first launch, and on iOS, AdAttributionKit covers installs and re-engagement from ads shown in other apps; it does not attribute clicks from your own website, email or QR codes, and it never routes one person to a screen. Decide whether first-launch routing is worth the work for each campaign type; the measurement guide sets out what each tool returns.

Step 6: test every row

Open each mapped link with the app installed and not installed, on Android and iOS, and record the result with the date and app build. Faults that appear only after a migration, such as a forgotten redirect on the file host, are listed in the taxonomy of broken app links.