Author:Shir Keren
Shir Keren works at AppMakers USA as a Project Manager and QA Analyst, keeping teams aligned and releases dependable. She supports planning, day to day coordination, and hands-on testing, with a strong focus on usability and detail. Outside the studio, she is usually hiking with her dog, cooking something new, or working on creative side projects.
Firebase Dynamic Links (FDL) shut down on August 25, 2025. If an app relied on FDL for QR codes, referral links, onboarding links, or campaign URLs, a lot of “it still works” links quietly stopped working. That includes printed QR codes that can’t be recalled and old content that still ranks in search.
This guide explains what to replace FDL with in 2026, how to rebuild a link system that does not dead-end, and how to test it so users actually land where they expect.
Step 1: Inventory and triage (do not guess)
Before rebuilding anything, teams need a clean inventory. Link migrations fail when they start with implementation and skip discovery.
What to inventory
Start with the places links hide for years:
- QR codes on packaging, signage, flyers, or receipts
- Old email templates and SMS flows
- Referral and invite links
- Blog posts, landing pages, and help center articles
- Paid ad URLs and tracking sheets
- In-app “share” links
If FDL was used, common traces include page.link domains and old redirect endpoints.
How to triage
Not all broken links are equally painful. Prioritize in this order:
- Anything tied to revenue (checkout, subscription offers, coupon links)
- Anything evergreen and hard to update (printed QR codes, long-lived docs)
- High-traffic sources (top landing pages, top campaigns)
The goal is to stop the bleeding first, then rebuild properly.
Step 2: Rebuild the foundation with OS-native linking
FDL hid a lot of complexity. In 2026, the foundation should be OS-native deep linking:
- Android App Links / deep links
- iOS Universal Links
These let the OS open the app directly when it is installed, instead of bouncing through a third-party redirect.
Android: App Links and deep links
Android supports deep links that map URLs to in-app screens. App Links are the “verified” version, where the OS can trust the association between the domain and the app.
Implementation details vary by stack, but the core rule is consistent: define stable URL patterns that map cleanly to routes.
Example route map:
- /offer/{id}
- /invite/{code}
- /order/{id}
iOS: Universal Links
Universal Links let standard HTTPS URLs open the app when installed, using an associated domain configuration.
The win is reliability for installed users, but the tradeoff is that setup has to be correct, including the app site association file and route matching.
Practical rule: keep routes stable
Marketing teams change campaigns. Product teams change UI. Deep link routes should not change often.
Treat routes like an API. If they break, everything breaks.
Step 3: Add a link router (the part FDL used to hide)
OS-native linking solves the “installed user” case. It does not solve everything.
A link router is still needed to:
- handle “not installed” behavior
- preserve tracking parameters safely
- route users to the right store page
- provide a fallback web page that explains what happens next
What a good router does
A clean router flow looks like this:
- User taps a short link (or scans a QR code)
- Router detects platform
- If installed, Universal Link/App Link opens the app
- If not installed, router sends to store (or a web fallback)
The router should be owned and versioned like a real system. “Random redirect rules in a dashboard” is how links rot.
Preserve marketing parameters safely
The router should preserve UTM parameters and campaign identifiers without turning the URL into a security problem.
Two common mistakes:
- passing sensitive data in query strings
- letting arbitrary parameters control app behavior
Treat the router as a gatekeeper. Validate what it passes forward.
Build a human fallback page
If the app is not installed, do not dump users on a generic store page with no context.
A good fallback page:
- restates the promise (“You’re about to open Offer X”)
- shows the next step (“Install to continue”)
- handles the common objections (pricing, device compatibility)
This is also where conversion improves. Context reduces drop-off.
Step 4: Deferred deep linking reality (what is feasible)
“Deferred deep linking” means: user clicks a link, installs the app, and still lands on the intended screen after first open.
This is the part many teams overpromise.
Android: Install Referrer is the standard primitive
Android provides the Play Install Referrer mechanism so apps can understand install attribution and some campaign context.
The practical approach on Android is:
- store route intent server-side when the click happens
- use referrer parameters to reconnect the install to that intent
- send the user to the correct route on first open
iOS: set expectations
Universal Links are strong for installed users. True deferred routing is more constrained and often relies on additional infrastructure or vendor tools.
The key is to avoid promising “perfect deferred deep linking everywhere” if the stack cannot reliably support it.
A better posture is:
- make installed routing flawless
- make non-installed routing clear and context-heavy
- implement deferred routing where it is reliably achievable
Step 5: Testing matrix (the part that prevents silent failures)
Link systems fail in edge cases. If teams do not test those cases, they ship broken experiences without noticing.
The minimum test matrix
Test:
- iOS installed
- iOS not installed
- Android installed
- Android not installed
- QR scan vs tap from browser
- Wi‑Fi vs spotty network
- First open after install
Common failure modes
- Wrong screen (user lands at home instead of the intended destination)
- Lost parameters (UTMs disappear or get overwritten)
- Looping redirects (router sends to a page that re-triggers the router)
- Universal Link/App Link not verified (opens browser instead of app)
- Router caching issues (old mapping persists)
A simple habit that helps: log “right-screen rate” (more on that below) during testing and after launch.
Step 6: Measurement that matters
Most teams measure store clicks. That is not enough.
The metric that exposes reality is: did the user land where they expected?
Track these three metrics
- Right-screen rate: % of sessions where the intended deep link route was reached
- Install to activation by entry route: which deep link destinations create real users
- Broken-link monitoring: 404s, redirect failures, and spikes in fallback usage
A practical monitoring cadence:
- weekly link health scan for top routes
- alerts when fallback usage spikes
- quarterly audit of evergreen QR codes and legacy pages
When to bring in engineering help
If the business depends on links working reliably, this should not be treated as a marketing-only task.
Link routing touches:
- app routing
- OS configuration
- security and parameter validation
- analytics and attribution
- long-term maintainability
If you need a router, secure param handling, cross-platform parity, and clean analytics wiring, experienced mobile app developers can implement it as a stable system instead of a chain of brittle redirects.
Conclusion
The lesson of the FDL shutdown is simple: “set it and forget it” link infrastructure is not real infrastructure.
In 2026, the safer approach is to build on OS-native deep links, use a router for controlled fallbacks, be realistic about deferred deep linking, and test with a real matrix. When links behave predictably, marketing performs better, users get less frustrated, and apps stop leaking conversions through broken routing.
