The Pulse #57: Google Shutting down Firebase Dynamic Links
Also: details behind the salary bands at Wise; Hopin selling its events tech business; Startup shutdowns trending up; and Uber posting its first operating profits.
Today's topics are:
Google shutting down Firebase Dynamic Links. Firebase Dynamic Links was a popular way to build universal deeplinks that worked across iOS, Android, and the web. Now after 7 years, Google is shutting down this product. But why? I asked the Big Tech giant for details. Exclusive.
Details behind Wise’s open engineering salary bands. How did Wise open their compensation bands? I got more details from Timothee Ledure, the former engineering lead at Wise, at their Singapore office. Exclusive.
Events tech company Hopin selling its events tech business. Hopin raised more than $1B in funding, but has now sold its ‘core’ business to RingCentral. I talked with current and former Hopin engineers to get more details on the sale, including the rumored price tag. Exclusive.
Startup shutdowns are, unfortunately, trending up. The ‘startup purge’ event that we predicted at the beginning the year would come seems to, sadly, be here. Data from Carta confirms an uptick in startup shutdowns. Analysis.
Uber posted its first operating profit. Profitable is not what most people think of when talking about Uber. And yet, the company has now delivered its first quarterly profits, and could well keep on being profitable. Why does this matter? Analysis.
The Pulse sometimes delivers first-hand, original reporting. I’m adding an ‘Exclusive’ label to news that features original reporting direct from my sources, as distinct from my usual analysis, opinion, and reaction to events.
1. Google shutting down Firebase Dynamic Links
Firebase Dynamic Links (FDL) is a neat service that allows you to create a ‘smart’ link, and that link transforms into:
An iOS deeplink when opened on an iOS device
An Android deeplink on Android
A web link when opened in a browser
There are several neat things about Firebase Dynamic Links:
You can customize the link behavior based on whether or not someone has your app installed. For example, you can decide to send users who don’t have the app to a place to download the app, send them to a website, or show them an interstitial site that describes the benefits of the app before sending them to the app store to install it.
They can “survive” an app installation: so if an iOS user were to open your link, they would be prompted to download the app, which they could then download, and once they have done so, they would get linked to the right part of the app.
It is possible to treat customers differently based on a campaign identifier on the link.
Use cases for Firebase Dynamic Links
This product is powerful and has many uses. But to focus here, I tried to sketch out below a reasonably common use case of directing users to a deeplink within iOS and Android, taking care of persisting this detail via the install, and offering an interstitial site on iOS before forwarding the user to the App Store:
This is how how Google describes the product, with one sentence:
“Firebase Dynamic Links are links that work the way you want, on multiple platforms, and whether or not your app is already installed.”
Firebase Dynamic Links worked out how deeplinks were supposed to function, whereas they often did not in other offerings! This product created a smart routing layer on top of dynamic links and web links, making it easy enough to configure and use. These links were especially helpful for:
Promotions and marketing campaigns
Content sharing links that “just work”
Converting desktop users to mobile ones
Dynamic links powered Firebase Invites: an app invite service where users could send app invite links to their friends, to drive installation of the app. Firebase deprecated the Invites product in 2020: presumably after a drop in the popularity of app invites, about 2 years after Facebook also deprecated their app invites product.
Now after 7 years, Google has announced it will retire Firebase Dynamic Links, but with no definite successor lined up. Since Google launched the product in 2016, it’s been viewed as a stable product within the Firebase product suite.
In May of this year, Google launched a Firebase FAQ page, where they are communicating that Firebase Dynamic Links will be deprecated, suggesting users should stop using it going forward:
“Firebase Dynamic Links is no longer recommended for new projects. In the future, the Dynamic Links service will shut down, but you will have at least 12 months from the announcement date to migrate. We will announce more information in Q3 2023.”
Because of how useful this product is, especially for app developers building on top of it, this announcement came as a surprise. Even more surprising is how Google does not even hint at a follow-up product. They instead seem to suggest to use other solutions going forward:
Android App Links for Android apps
iOS Universal Links for iOS apps
To me, it feels that Google is abandoning their original vision of having links that “just work” everywhere, and it’s unclear why. So I reached out to Google, asking the same questions, and here’s what I got as answers from a Google spokesperson (the bolding is mine)
Q: Will Google build a service Firebase Dynamic Links customers can migrate to?
A: “We won’t be providing a direct replacement for Firebase Dynamic Links, but we will be recommending and providing guidance on alternatives developers can use based on their needs on migrating away from Firebase Dynamic Links in the coming weeks.
For example, we’ve found that some developers greatly value the deep-linking functionality that allows them to direct users to specific places in their apps. They deem this to be more important than routing referred users to the right store to download the app, and providing a deferred deep-linking experience. For these developers, using App Links (for Android) or Universal Links (for iOS) is a viable alternative, although they would no longer be able to route and provide a deferred deep-linking experience to their users previously provided by FDL.
For developers who strongly care about a contextualized app experience on the first click before their app is even installed, we’ll be recommending App Clips and Google Play Instant as potential alternatives, although these options come at a higher development time/cost.”
Q: Can you share more reasons for sunsetting FDL? This was a popular service, and Google recognized the need for links that “just work” on any platform, early on.
A: “Over the years, the web and mobile ecosystems have evolved with technologies such as App Links, Google Play Instant, Universal Links, and App Clips. These make user journeys across apps and the web quite seamless and predictable for your users. We believe developers and their users will benefit more from adopting these native platform technologies directly and continue moving the ecosystem forward.
On the other hand, the original native APIs that Firebase Dynamic Links were based on also evolved and changed, and presented new challenges. For example, the ecosystem changes impacted our ability to provide a consistently stable experience for one of Firebase Dynamic Links’ core features - giving app users a smooth transition into the app post install, regardless of platform.
Instead of continuing to support a less than ideal experience, we decided to sunset Firebase Dynamic Links, and to refocus our resources on solving other developer pain points. Though we also understand that this change will require developers time to evaluate, decide, and adopt alternative solutions or platform providers in the market.
Importantly, we want to emphasize that we are continuing to evolve Firebase to meet the needs of developers as the ecosystem continues to also evolve and change. We’ll continue to launch new features and updates across Firebase products, and are committed to helping developers excel in their app development journeys.”
Hearing the reasoning behind sunsetting FDL, I cannot help but wonder if there might have been some platform-level changes, for example, on iOS, where the Firebase team deemed it too problematic to keep supporting the smooth transition to the post-app-install experience. If you have more insights on this, feel free to leave a comment!
Just as curious: Google is heavily promoting iOS native features, like Universal Links and iOS App Clips, despite Android being a competitor to iOS. I have not observed Apple do a “reverse” promotion, i.e., highlighting Android native features, and so this one-way “highlighting” is especially odd.
Firebase Dynamic Links alternatives
If you are an FDL customer, what vendors could you move to that are offering similar functionality? I asked this question, and here are the suggestion shared by developers:
Branch.io: “flawless mobile linking and attribution”
To Google’s credit, they came back to me offering non-vetted alternatives and are promising to provide a way to export existing deep-linking metadata. From the Google spokesperson I talked with:
“For developers that continue to need the set of features offered by Firebase Dynamic Links, we recommend developers use other deep-linking service providers / vendors, such as Bitly, Kochava, AppsFlyer, Adjust and other similar providers in the market. (Note, these providers have not been fully vetted, but do provide similar functionality to Firebase Dynamic Links). To make this migration easier and as seamless as possible, we will give developers the ability to export their deep-link metadata.”
I will give Google credit for giving well over a year of heads-up on their shutting down of FDL. A timeline of more than 12 months is generous, and by the time Google announces the definite sunset timeline in Q3 of this year, they will likely have given around 18 months’ notice. This is a lot more generous than is the case for Google Domains, which will shut down by the end of the year, leaving only around 9 months’ notice for all customers.
If you need to shut a product down, giving notice well ahead of the actual shutdown is the way to go, as well as building migration tools for customers. While retiring FDL will be painful for current customers, it’s at least nice to see Google closing this product in a considerate way.
Google’s product deprecation reasoning leaves a lot of second-guessing, still. A reader in the comments noted how Google’s shutting down of Firebase Dynamic Links rhymes with the Steve Yegge rant from 2020: Dear Google Cloud: your deprecation policy is killing you. And, indeed:
“In the Google world, deprecation means: “We are breaking our commitments to you.” It really does. That’s what it ultimately means. It means they are going to force you to do some work, possibly a large amount of rework, on a regular basis, as punishment for doing what they told you to do originally — as punishment for listening to their glossy marketing on their website: Better software. Faster! You do everything they tell you to do, and you launch your application or service, and then, bang, a year or two later it breaks down.”
When Google launched Firebase Dynamic Links, they explained the vision behind this product like this:
“That’s why we’ve created Firebase Dynamic Links: they’re deep links that work the way you want them to. With one single link, you can send users either to your iOS or Android app, if they have it installed. And if they don’t, you can send then to the appropriate listing in the App Store or on Google Play. Most importantly, these links survive the installation process, so when a user starts up their app for the first time, you can still retrieve the deep link URL that brought them to your app in the first place.”
One thing that is distinctively different than with the Google Cloud story is how those were deprecations with viable migration paths. Firebase Dynamic Links has none. And so we’re left to wonder: has native mobile — and, specifically, iOS — changed enough to render deeplinks that survive app installs to be infeasible, as a product, going forward? And if so: will other vendors keep finding workarounds, or will they also have to throw in the towel on universal deeplinks on all platform, like Google seemingly has?
2. Details behind Wise’s open engineering salary bands
A week ago, when covering what it means to be a senior engineer at scaleups, I shared an image summarizing the public base salary ranges from Wise’s website. Specifically, this image:
This level of transparency is commendable, especially as very few companies share even their salary ranges in public. So what happened at Wise that the company decided on this approach?