Firebase Dynamic Links shut down: repair old links, app invitations and email sign-in
A link opens your app but loses the invitation or sign-in screen. Separate old URLs, app routing, install handoffs and authentication before deciding what to replace.
A customer taps an invitation in an email and gets an error page. A replacement link opens the app, but only at its home screen. Calling both failures a deep-link bug hides the useful question: at which step does the customer’s journey stop?
Google set the Firebase Dynamic Links shutdown for 25 August 2025, covering both custom domains and page.link URLs. In 2026, treat a remaining dependency as recovery work rather than an approaching migration deadline. This is a repair and acceptance guide, not a customer case study.
Firebase — Dynamic Links deprecation FAQ
Split the problem into four stages
Trace one link still in use from receipt to completion. For a membership invitation, ask four questions: does the email URL resolve; does the installed app reach the invitation; can a new installation resume it; and does the correct account accept it? URL resolution, routing, install continuity and identity checks need separate answers. “The app opened” is only an intermediate result.
- Inventory entry points: email templates, SMS, WhatsApp, websites, push messages, printed QR codes and in-app sharing.
- For each link, record its domain, purpose, destination, generator, sign-in requirement and whether it can be reissued.
- Include older app versions and the current store release. A working development build is insufficient.
Your server cannot rescue an old page.link URL
Start with domain ownership. Google’s page.link domains cannot be retained or transferred. A redirect on your website cannot intercept a request to that old domain. Replace editable entry points and reissue invitations; provide a clear recovery route for emails already sent and material already printed.
An owned custom domain may allow a replacement HTTPS handler for known paths. Domain control alone does not recover the destination behind every short code. Look for saved exports, database mappings, sent-message records or campaign inventories. Without that mapping, recovery is uncertain. Firebase says old link metadata was marked for deletion at shutdown; do not build today’s plan around a fresh export being available.
Choose the behaviour before the replacement
If the requirement is to open specific content in an installed app, evaluate Android App Links and Apple Universal Links with a useful web fallback. “Tap invitation, visit store, install, then resume that invitation on first launch” additionally needs deferred deep linking. Sending someone to a store does not fulfil that requirement.
Compare services such as Branch or AppsFlyer against explicit continuation: reopen the email after installation, enter a short-lived invitation code, or view pending invitations after sign-in. A small membership workflow may need only that simpler route, provided the next step is clear. Ask vendors to demonstrate your device and channel combinations, and review charges, data collection, domain ownership, exports and exit arrangements. “Supports deep links” does not establish feature parity.
Firebase — Migrate to App Links and Universal Links · Branch — Firebase Dynamic Links migration
Give email sign-in its own acceptance check
Firebase Authentication provides a Hosting-based replacement for mobile email links. Check more than the SDK: link-generation settings, mobile handling of the new domain, and completion of the intended sign-in action all matter. Follow the Android and iOS migration instructions separately. For Flutter, React Native or a low-code builder, inspect the underlying native SDK and build configuration too.
Keep expiry, one-time-use and account checks. An invitation and a sign-in link serve different purposes: possession of an invitation URL should not bypass the server’s checks on account, invitation status and permissions. Record journey outcomes and error categories without collecting complete authentication URLs, codes or tokens.
Test opening the email on another device. Firebase email-link sign-in checks the recipient address; do not put an email address in the URL and trust it as proof. Test password reset and email verification separately. The Dynamic Links shutdown does not mean all Firebase web email actions were discontinued.
Firebase — Android email-link migration · Firebase — iOS email-link migration · Firebase — Email-link authentication and security
Test the message your customer actually receives
Pasting a URL into a browser tests only one entry point. Email delivery tools may wrap it in a tracking link; WhatsApp or another app may use an embedded browser. Keep an actual received test email and inspect the first clicked hostname and subsequent redirects, rather than testing only the final destination.
On Android, check App Links verification and the release signing certificate. On iOS, check Associated Domains and apple-app-site-association. Increasing a timeout does not repair a domain association. Establish whether the platform hands the URL to the app before debugging navigation within it.
On iOS, entering a URL in the browser address bar will not launch the app, and navigation within the same website may stay in the browser. Tap the link in the test message for acceptance; do not mistake expected browser behaviour for a failed repair.
Android Developers — Verify App Links · Apple Developer — Debugging universal links
Define completion with repeatable checks
A first release can restore one priority use case, such as email sign-in for existing members. Use the following checks as a starting point and specify the actual expected result for your workflow. Record app version, OS, entry channel, sign-in state and final outcome, including failure handling and support instructions.
- Installed app: both a cold start and an already running app reach the intended content; required sign-in preserves the destination.
- No app installed: the next step is clear; require automatic post-install continuation only if it is part of the agreed scope.
- Expired, used or revoked invitation: show a clear result and a safe reissue route; repeat taps create no duplicate membership or order.
- Different account or device: identity and permissions remain correct; sensitive content stays out of public previews.
- Actual delivery and sharing channels, the store release and supported older versions are tested; failures are traceable without logging sign-in secrets.
Give a repair team the journey and a failure sample
Prepare a reproducible test link, store URLs and versions, domain inventory, message generator, priority journeys and any old-link mapping. A test account and redacted screenshots are more useful than “Firebase is broken.” Arrange appropriate access when needed instead of emailing administrator passwords or service-account keys.
Separate investigation, URL handling, app updates, message-generation changes and acceptance in the scope. Allow for store review and users updating their app. A retired service is no rollback target; prepare a tested web or manual continuation route. Handover should include domain and route mappings, test results, monitoring and ownership of future updates.
