Deprecated SDKs and APIs — why your app stops working when nobody changed it

Users report that a link from your newsletter opens an error page and password reset has stopped working. Nobody shipped a new version of the app or touched the backend. The cause lies outside the app: a service it relied on has been shut down.

A typical mobile app is largely made of other people’s code. Login, payments, analytics, maps, notifications, crash reporting — behind each of these features is a third-party SDK or API. Each has its own lifecycle, and its provider deprecates it on their schedule, not yours. Your app doesn’t have to change to stop working.

Three ways a deprecated SDK breaks your app

1. The provider shuts the service down. This is the most dangerous case: the failure happens without any release and hits every version of the app at once.
2. The store blocks releases that use an old library version. The app keeps working, but you can’t ship a new version until you update the dependency. This usually surfaces when you need to push out a fix quickly.
3. The library is deprecated with no shutdown date. Nothing happens today. But the library gets no fixes, and a date can be announced at any time.

Examples from recent years

One thing connects these cases: the deadline was known well in advance. Google announced the Dynamic Links shutdown in 2023, two years ahead. Billing Library follows a fixed two-year deprecation cycle, and the deadline table for upcoming versions is public. We cover push notifications and the shutdown of the legacy FCM API in more detail in our article on why push notifications stopped working.

It is also worth knowing that a shutdown doesn’t always mean a crash. Firebase explains that the Dynamic Links SDK itself won’t take down your app, but it will start returning errors or empty data. The app launches and the feature quietly stops working. You won’t see that failure in a crash report, only in user complaints or a drop in conversions.

Why nobody notices

Providers do send warnings, just not where the app owner is looking:

• emails go to the address on the Firebase, Google Cloud or developer account, often the inbox of a developer who left long ago,
• Play Console shows SDK warnings on release pages that only get opened when publishing,
• deprecation notices sit in library release notes that nobody reads while the project isn’t being developed.

It is one of the five signals we describe in our article on how to tell your app is quietly dying.

Inventory: what your app is made of

The first step is a list of dependencies. A developer will find it in a few places:

• Android: build.gradle or build.gradle.kts and libs.versions.toml,
• iOS: the Podfile or Swift Package Manager dependencies,
• Flutter: pubspec.yaml, React Native: package.json.

Two more groups don’t show up in the app’s code. The first is backend integrations: purchase validation, sending notifications, map or payment requests. The second is services configured in provider dashboards, such as link domains or Firebase projects.

For each item, it pays to record a few details:

You can check the provider status in documentation and release notes. Play Console helps too: it shows warnings when an app uses an SDK version that its provider has reported as outdated or as having critical issues, and in some cases it blocks further releases with that version.

In what order to replace them

1. Services already shut down that the app still uses. These are failures happening right now, even if nobody has reported them yet. Check Dynamic Links, App Center and how notifications are sent, at the very least.
2. Deadlines that will block releases in the coming months. Miss one and every urgent fix will start with a library upgrade.
3. Deprecated libraries in business-critical features. Replace login and payments calmly, before the provider announces a date.
4. Everything else. Update these as part of routine maintenance, in small steps.

Replacing a library isn’t always a version bump. Billing Library changes its API between major versions, and moving from Google Sign-In to Credential Manager means rewriting the login flow. Such work is best released on its own, without new features, so that if something goes wrong you know where to look.

Old versions in users’ hands

When a provider shuts a service down, a fixed version of your app only helps the people who install it. Everyone else keeps using a version that calls a service that no longer exists.

That’s why it is worth having a minimum version mechanism before you need it. On Android, Google offers In-App Updates with an immediate mode: a full-screen prompt requires the user to update and restart the app. iOS has no equivalent, so the app itself checks a minimum version fetched from the backend or remote config and shows an update screen. The mechanism has to be in the app beforehand — added only in the version with the fix, it won’t work in older versions.

How not to get caught out

• Contact addresses on your accounts in Google Play, Apple, Firebase and Google Cloud should point to a company inbox read by more than one person.
• A dependency register with deadlines entered in the calendar, a few months ahead.
• A quarterly dependency review and small, regular updates instead of one big jump every few years.
• Monitoring of crashes and key flows that shows a problem sooner than user complaints. We describe it in our article on mobile app crash monitoring.
• A clause in your maintenance contract stating who is responsible for tracking deprecated dependencies. More on this in our article on what to put in a mobile app maintenance contract.

Regular library and SDK updates are a standard part of the mobile app maintenance we provide. If you don’t know which SDKs your app uses and which of them already have a deadline, order a free app analysis. Among other things, we check how far behind the libraries, SDKs and targetSdk are, and you get the results in writing.