The technological landscape is ever-changing, and the need to stay ahead is more important than ever. One major shift in what has become an industry standard relates to Firebase Dynamic Links - a seamless way to guide your users to the right content. As Google is about to sunset their service, what should developers and Product Owners do to maintain their user frictionless user journey?
In this piece, I’ll delve deeper into the following:
Let’s get right into the action and explore the world of Firebase Dynamic Links alternatives.
Deep links are a form of a link that sends the user directly to the desired content within an app; it is done contrary to what a ‘traditional’ link would do which is to open a webpage or, in the best case, the app’s homepage and force the user to navigate to the content they want to see manually. For instance, when you open a deep link pertaining to a specific song on Spotify, upon clicking it, you’d see the app open and go directly there.
It is not a mere user convenience tool, though. It can be an effective marketing and sales tool to send the user to a specific offer page, for instance.
Now that we know what Deep links are, let’s explore Universal Links and App Links. These two terms refer to solutions for handling web HTTPS links for deep-linking purposes on iOS and Android, respectively.
However, they also have a unique upside - namely seamless fallback. If a link that is being opened tries to open an app and, for whatever reason, it cannot (most commonly because the app isn't installed), a fallback is initiated and the system will open the default browser and show the content in its web form. This ensures that the user always accesses the content - even when the app isn't available or there are some mobile issues.
Let’s build on what we already know and add a set of further unique advantages. Firebase Dynamic Links are not simply what Universal Links and App Links are; rather, they provide a sophisticated additional layer on top of those native functionalities, offering even more value.
The first trademark feature is Deferred Deep Linking. We discussed a situation where a web link might open a web browser if the app wasn't installed. With Deferred Deep Linking, the system would be triggered to direct you to the app store so that you could download the app immediately. Crucially though, and this is where the magic happens, it would also ‘remember’ the original link and, upon installation, redirect you directly to the desired content! This was invaluable for user acquisition campaigns, ensuring a highly personalized first-run experience.
Furthermore, Firebase Dynamic Links provided intelligent, cross-platform routing. It wouldn’t concern itself with whether we’re dealing with Android, iOS, or a desktop web browser. You’d have a one-stop shop where a single link would work seamlessly in any environment, as it would intelligently detect the user’s device and app status, then route them to the most appropriate destination.
Last but not least, it has built-in analytics that’s invaluable to marketers and Product Owners. One could track link clicks, app installs resulting from those clicks, and subsequent in-app events. Measuring campaign effectiveness and understanding the full user journey from click to conversion was made much easier.
While it all sounds very useful, sadly the technological landscape is changing and, with that, Firebase Dynamic Links are deprecated.
Google has announced that Firebase Dynamic Links will be deprecated in the summer of 2025, namely on August 25. This means that the service will no longer be actively maintained, supported, or developed by Google beyond this date. In other words, all existing Firebase Dynamic Links will cease to function as dynamic links.
Therefore, users who click on these links will not be redirected to specific content within the app, nor will they take advantage of deferred linking. This is a complete loss of that praised seamless experience. In fact, in specific cases where teams did not connect their own custom domain to Firebase Dynamic Links, users may be met with a "404 not found" error, leading to a frustrating and broken user journey.
However, instead of mourning what is to be gone, let us direct our attention at the solutions.
Let us take a look at two key cases when it comes to a potential migration of your deep linking after Firebase Dynamic Links deprecate.
If you need to take advantage of all the unique features we have discussed (deferred deep linking, analytics, cross-platform routing), you might want to consider Third-Party services from companies like Adjust, Airbridge, ApssFlyer, Bitly, Branch, or Kochava. While they are not officially endorsed by Google, their offering does align with what you usually get with Firebase Dynamic Links. This is not a perfect solution by any means, but I’ll get into it more later in this piece.
If you mainly care about proper redirection to specific content within an installed app, you can use the previously discussed system-specific solutions - Universal Links and App Links. It’s a much more basic approach, but it might get the job done for you without having to use a third-party service.
When it comes to analytics, you have a couple of choices. First, you can export all the existing data from Firebase to ensure you don't lose it. That is the first step in preserving all the information.
As for the future, you can:
In this chapter, let us take a closer look at Firebase Dynamic Links alternatives.
The two big groups of solutions are Third-Party Services and Dedicated Per-App Set up (Universal Links and App Links)
Third-Party services are solutions offered by specialized private companies that come with a ton of out-of-the-box functionalities for mobile linking, analytics, and routing. Some prominent examples of such services include Adjust, AppsFlyer, Bitly, Branch, and Kochava.
The pros that come with this approach are numerous. You would benefit from very fast implementation with minimal backend development, mainly relying on SDK integration. This translates to a very fast turn-around time from decision to action. You’d also gain access to powerful features that replicate and enhance Firebase Dynamic Link functionalities, such as robust analytics, intelligent cross-platform routing, and crucially, deferred deep linking. Furthermore, these services typically provide dedicated support and ongoing maintenance, relieving your team of that burden.
On the other side of that coin, we have a couple of downsides that are worth mentioning. Vendor lock-in is a significant consideration, as it builds a dependency on an external provider that is often unwelcome for businesses seeking full autonomy. Moreover, one has to examine the pricing structure carefully to ensure it aligns with budget constraints and scalable usage. Last but definitely not least, passing sensitive data (e.g., invite codes, reset codes, Personally Identifiable Information - PII) through a third party is generally not advisable to ensure security and compliance. If such data is embedded in the link, it ‘stays’ in browser history, server logs, and can be intercepted. There are also inherent concerns about a third party's access to sensitive information and whether they will consistently uphold all necessary data compliance standards (e.g., acting as an unwanted sub-processor).
The estimated development cost is typically low, ranging between 1-2 days of quick integration, mostly involving configuration and testing.
The second solution is to have a dedicated per-app setup using Universal Links for iOS and App links for Android. This method involves using native linking mechanisms in conjunction with a fallback page - which, as we discussed previously, is used to redirect users to when an app is not installed.
The first crucial upside is that you are independent from any third-party vendor. This removes any reliance on what your service provider might or might not do - such as aforementioned upholding of compliance standards or sudden change of the pricing structure. On top of that, you get full control over your User Experience and routing, as you manage every aspect of the linking process. Naturally, there are also no recurring costs, as there’s no service that you’re using on an ongoing basis. Last but not least, it’s a one-time set-up with minimal required maintenance.
There are some key considerations though, as it’s not all pure upside. It is a longer process so the turnaround time doubles or triples, depending on in-house expertise. You don't have any analytics out of the box, so it's entirely up to you to set it up.
Lastly, achieving a seamless deferred deep linking experience is possible, but it requires careful custom implementation on both the frontend and backend.
Therefore, you can count on either the user having the app already installed or use a fallback web page, or go through a complicated setup to enable a deferred deep-link functionality.
The estimated development cost for this approach is medium-to-high, typically around 5 days. This represents a one-time setup effort, which may involve some trial-and-error, particularly on mobile platforms
Let’s take a look at the full comparison.
Third-Party Services | Dedicated Per-App Setup |
---|---|
Description | |
Description | Description |
Platforms that handle dynamic link routing, app detection, deferred deep linking, and redirection via SDKs and dashboards. | Using iOS Universal Links + Android App Links with a static HTML fallback page for app store redirects. |
What's Required | |
What's Required | What's Required |
Integrate SDK into a Flutter app. | HTTPS server, platform-specific verification files, Flutter configuration for deep links, manual link creation. |
Estimated Development Cost | |
Estimated Development Cost | Estimated Development Cost |
Low (1–2 days) | Medium-to-high (5MD integration + Flutter libs) |
Pros | |
Pros | Pros |
Fastest to implement, analytics, deferred deep links | No third-party dependency, one-time setup, no recurring costs, full control over UX. |
Cons | |
Cons | Cons |
Vendor lock-in, potential cost, SDK dependency, can't pass sensitive data. | Limited deferred deep linking, no out-of-the-box analytics, longer turn-around time |
Third-Party Services | Dedicated Per-App Setup |
---|---|
Description | |
Description | Description |
Platforms that handle dynamic link routing, app detection, deferred deep linking, and redirection via SDKs and dashboards. | Using iOS Universal Links + Android App Links with a static HTML fallback page for app store redirects. |
What's Required | |
What's Required | What's Required |
Integrate SDK into a Flutter app. | HTTPS server, platform-specific verification files, Flutter configuration for deep links, manual link creation. |
Estimated Development Cost | |
Estimated Development Cost | Estimated Development Cost |
Low (1–2 days) | Medium-to-high (5MD integration + Flutter libs) |
Pros | |
Pros | Pros |
Fastest to implement, analytics, deferred deep links | No third-party dependency, one-time setup, no recurring costs, full control over UX. |
Cons | |
Cons | Cons |
Vendor lock-in, potential cost, SDK dependency, can't pass sensitive data. | Limited deferred deep linking, no out-of-the-box analytics, longer turn-around time |
Let’s get into the crux of the problem. How should you choose your own solution?
You should definitely take a close look at the following:
We at LeanCode will happily help you with your Firebase Dynamic Links being deprecated.
We offer a range of services such as:
As Google sunsets Firebase Dynamic Links, you are now well-equipped with the knowledge to be solution-driven in this situation. With the full overview of the situation, you can make an informed decision on how to progress your technical solutions for your frictionless user experience.