Deferred deep linking used to sit in silence behind many mobile growth journeys. A user tapped a link in an SMS, RCS, or Viber message, installed the app, and arrived on the originally intended in-app screen. FDL used to handle that route for many teams. Since Firebase Dynamic Links shut down on August 25 2025 though, those links no longer provide a working foundation for acquisition, referral, or re-engagement flows.
So, what now?
The replacement does not simply involve finding a short-link vendor. A durable setup starts with platform-native linking: iOS Universal Links and Android App Links, verified against a domain your brand controls. A branded short domain then becomes the campaign-facing layer: it keeps the link recognizable, supports routing and attribution, and connects messaging channels to the app without relying on a disappearing vendor-owned link system.
In this guide I focus on the architecture that matters post-shutdown: how native deep links work, what a Firebase Dynamic Links alternative needs to cover, how deferred routing preserves campaign context through installation, and when RCS or Viber buttons should be paired with visible branded links and fallback paths.
Deep linking foundations: Universal Links and App Links as the durable base
A deep link opens a specific screen in an installed app. A deferred deep link preserves that destination when the app is not installed yet while the user goes through the app store, installs the app, and finally arrives at the intended screen on first open.
After Firebase Dynamic Links ceased operations, the stable foundation is no longer a vendor-owned routing mechanism. Now the base becomes the native linking architecture built into each mobile platform:
| Platform | Native mechanism | Domain association file | What it proves |
|---|---|---|---|
| iOS | Universal Links | apple-app-site-association (AASA) | Your domain is authorized to open specific paths in your app |
| Android | App Links | /.well-known/assetlinks.json | Your website domain is associated with the verified Android app |
On iOS, the app declares its associated domains, while the branded domain hosts the AASA file that defines which URL paths the app can handle. On Android, the app declares verified link intent filters, and the domain hosts assetlinks.json, which connects the domain to the app package and signing certificate.
Both setups depend on the same principles:
- the domain is controlled by your organization
- the association file is available over HTTPS
- the verification endpoint resolves immediately, without redirects
- the app is configured to handle the relevant URL paths
What’s worth keeping in mind is that a branded campaign link may use redirects as part of the user journey but the operating system must be able to verify the domain-app association directly. A missing file, incorrect Android certificate fingerprint, or redirect on the verification endpoint can cause the link to open in a browser instead of the app.
💡 This makes Universal Links and App Links the durable base for mobile app deep linking: they establish a verified relationship between your domain and your app at operating-system level. A short-link or attribution platform can sit above that foundation but it should not be the foundation itself.
Firebase Dynamic Links: What the shutdown means in practice
Firebase Dynamic Links combined several jobs in one service: routing users into an installed app, carrying context through installation, supporting campaign parameters, and providing fallback behavior when the app could not open.
❗ Google shut the service down on August 25, 2025. Existing Firebase Dynamic Links no longer work, which means any live campaign, onboarding flow, referral path, or re-engagement journey still depending on them needs a replacement.
The risk, however, is not limited to broken links. An SMS marketing invite may stop opening the registration screen. An RCS install campaign may send users nowhere useful after the tap. A referral link may lose the context needed to credit the original user. In each case, the failure happens at the point where a message is supposed to become an app action.
A Firebase Dynamic Links alternative should therefore not be evaluated as a one-for-one short-link replacement. A durable architecture will haved two layers:
- Native app routing: iOS Universal Links and Android App Links establish the verified domain-to-app relationship.
- Campaign routing and measurement: A branded short domain handles visible campaign links, fallbacks, UTM parameters, and click analytics.
Third-party mobile measurement platforms such as Branch, Adjust, or AppsFlyer may still be useful when you need advanced attribution, install matching, fraud controls, or cross-channel measurement. But they are optional measurement tools, not substitutes for correctly configured Universal Links and App Links.
The post-shutdown FDL shift is straightforward: build the app-opening path on platform-native mechanisms, then add the branded routing and analytics layer your campaigns require. That approach reduces dependency on a single vendor-owned link service while preserving the user journey from message click to app destination.
How deferred deep linking works and how to measure it honestly
Deferred deep linking keeps the intended in-app destination when the user does not yet have the app installed. Instead of losing the campaign context at the app store, the flow should restore it after installation and first launch.
A typical messaging journey looks like this:
- A user clicks a branded short link in an SMS, RCS, or Viber message.
- If the app is installed, an iOS Universal Link or Android App Link opens the intended screen directly.
- If the app is not installed, the user is routed to the appropriate app store.
- After installation, the app retrieves the original context and opens the intended screen, such as a product page, order status view, referral reward, or saved offer.
For example: sms.brand.com/order/8429 may open order 8429 immediately for an existing app user. For a new user, it should lead through installation and still open the same order-related destination on first launch.
A branded short domain fits into this flow as the campaign-facing routing layer. It gives the sender a controlled, recognizable URL and can carry the campaign logic required for tracking and fallback decisions.
It does not, by itself, reproduce every deferred deep linking function Firebase Dynamic Links used to provide. Preserving context through an install requires app-side handling and, depending on the attribution depth required, may also call for a mobile measurement or deep-linking provider.
Honest measurement after the click
The most accurate measurement setup separates four signals:
| Signal | What it measures |
|---|---|
| Short-link click | Initial engagement with the message CTA |
| Store visit or install | Whether the journey led to acquisition |
| First app open with restored context | Whether the deferred route worked |
| In-app conversion event | Whether the user completed the intended action |
Keep UTM parameters on the destination or campaign-routing URL so web-based landings can still be attributed in GA4. For app journeys, align in-app event names and campaign identifiers with the web measurement structure so that the funnel can be compared across destinations.
Do not treat every short-link request as a human click. Link previews, security scanners, bots, and repeated requests can inflate click counts, particularly in rich messaging environments. Clean reporting should filter non-human traffic and deduplicate the relationship between click, install, first open, and conversion. Otherwise, a single user journey may appear as several separate successes.
Deferred deep linking on iOS
On iOS, Universal Links provide the verified app-opening route, but deferred attribution becomes more constrained once the user moves through an install. Privacy controls, including App Tracking Transparency, limit deterministic matching in some scenarios. A branded domain and consistent campaign parameters preserve the minimum reliable foundation: you know which campaign URL was clicked and can measure later app events within the attribution method your setup supports.
💡 The reasonable approach is simple: measure deferred deep linking as a funnel instead of a click count. A short link has done its job only when the intended post-install context survives and the user reaches the action the campaign promised.
Fallback discipline: App, store, and mobile web
The ideal outcome of a deep-link campaign is a specific in-app screen, but every branded link must also handle users without the app, users on unsupported devices, and journeys where deferred routing cannot be completed, so you need a fallback path as well.
Plan for four scenarios:
| Scenario | Expected result |
|---|---|
| App installed | Universal Link or App Link opens the correct in-app screen |
| App not installed | User reaches the correct App Store or Google Play destination |
| App installed after the click | Deferred deep linking restores the intended context on first open, where supported by the chosen implementation |
| Desktop or unsupported device | User reaches a mobile-friendly web destination, not an error page |
Do not treat web fallback as a minor exception. Think of it as the safety net for cases where the native route fails, the app is unavailable, the device is unsupported, or privacy constraints prevent a reliable deferred match. If the original CTA was “Track order”, the fallback page should still let the user track the order. If it was “Complete purchase”, the mobile web destination should preserve that task as far as possible.
A branded short domain can act as the visible entry point for all of these routes: sms.brand.com/order/8429
Behind that URL, routing rules can direct an installed-app user toward the native app path, a new user toward the appropriate store journey, and an unsupported user toward mobile web. The domain keeps the campaign URL consistent, the native app configuration and any deferred-linking or attribution layer determine how much context can be restored after installation.
This is applicable with RCS as well. An Open URL action can send the user into the app or web journey but the fallback destination still needs to complete the same job when the preferred route is unavailable.
💡 The implementation principle is straightforward: define the app destination first, map the equivalent store and web outcomes, then test every route before launch. Deep linking improves conversion only when no user is left at a dead end.
When buttons beat visible links and when they do not
In RCS and Viber the default CTA for a direct action should usually be a button. For things like Track order, Pay now, Reorder, or Open offer a button reduces visual clutter and gives the user a clear next step without exposing the underlying URL.
A visible branded link is still valuable when the message may be copied, forwarded, previewed, or delivered through an SMS fallback. In those cases, the domain becomes part of the trust signal: go.brand.com/pay is immediately easier to recognize than a generic short URL.
| Use case | Better default | Why |
|---|---|---|
| Immediate action in RCS or Viber | Button | Clearer CTA and less friction |
| SMS fallback from RCS journey | Visible branded link | The recipient sees the raw URL |
| Message likely to be forwarded or copied | Visible branded link | The destination remains identifiable outside the original interface |
| Link may appear in a preview | Branded domain behind the button or link | Domain recognition still supports trust |
| Complex app/web/store routing | Button backed by branded link logic | Cleaner UX without sacrificing controlled routing |
Buttons do not remove the need for a branded short domain. An RCS user may receive a button, while a recipient on an unsupported device receives the SMS fallback with a visible URL.
Similarly, a Viber link may later be copied into another context where the original button interface no longer exists. The routing and domain strategy must remain credible in every version of the journey.
Users are cautious about links in text messages. Proofpoint research shows that 75% of organizations experienced smishing in 2023 and that URLs appeared in 55% of suspected smishing messages. A recognizable domain does not replace security controls but it does reduce ambiguity at the moment of decision.
💡 The rule is simple: use buttons when the interface can make the action effortless, use visible branded links where the URL itself may be seen, reused, or relied on as a trust signal. In both cases, the branded domain should remain the stable entry point for routing, fallback, and measurement.
Building a durable app-link journey after Firebase Dynamic Links
The shutdown of Firebase Dynamic Links made one point clear: mobile campaign routing should not depend entirely on a vendor-owned link mechanism. The more durable foundation is a verified relationship between your own domain and your app via iOS Universal Links and Android App Links.
A branded short domain then becomes the stable campaign entry point across SMS, RCS, Viber, QR codes, and fallback journeys. It can keep the visible link recognizable, route users according to device and app availability, preserve campaign parameters, and support click measurement. Where advanced install attribution or deferred matching is required, an MMP or deep-linking provider can be added above the native foundation rather than replacing it.
There are three core principles for you to follow:
- Build app opening on platform-native links. Vendor services can add measurement or routing capabilities but Universal Links and App Links should anchor the architecture.
- Use a branded short domain across messaging journeys. One controlled URL can support app routes, store journeys, mobile web fallbacks, and campaign analytics.
- Treat fallback as part of the experience. Buttons may create the cleanest UX in RCS or Viber, but branded links preserve trust and continuity whenever the URL becomes visible.
If you are running cross-channel messaging campaigns, MessageFlow can provide the branded, trackable link layer that connects campaign traffic with controlled routing and measurement across messaging channels. The app-link and deferred-linking implementation still needs to be designed around the mobile product’s native requirements but the campaign-facing link should remain recognizable, measurable, and under your control.
FAQ – Deferred deep linking
A deep link opens a specific screen in an app that is already installed. A deferred deep link preserves that destination when the app is not installed yet, routing the user through installation and then to the intended in-app screen on first open.
Not for the native foundation. iOS Universal Links and Android App Links connect your domain with your app. A third-party service may still be useful for advanced install attribution, deferred matching, fraud controls, or cross-channel reporting.
You need an HTTPS domain, an apple-app-site-association file hosted on that domain, and the Associated Domains capability configured in your iOS app. The verification path must not redirect. Restoring context after installation requires an additional deferred-linking mechanism.
If RCS falls back to SMS, a button-based CTA may become a visible URL. Plan the fallback so the user still reaches the relevant app screen, app store page, or mobile web destination. A branded short link preserves trust when the URL becomes visible.
Not by itself. A branded short domain can handle the visible campaign link, routing, tracking, UTMs, and fallbacks. Native app opening still requires Universal Links and App Links, while advanced post-install attribution may require an additional provider.
