End of Life Software in 2026: What to Do If Your App Still Runs on It

Here is the thing that makes this problem so easy to ignore: software that has stopped being supported does not stop working. It has no expiry date, no warning light, no message on a screen. The morning after the last patch is written, your app opens exactly as it did the day before, and it will keep opening for years.

That is precisely why so much of it is still out there. Nothing forces the conversation. The bill arrives later, all at once, and usually at the worst possible moment.

A handful of tools that a great deal of working software still depends on have now gone quiet for good. This is what that actually costs you, how to find out whether you are affected without being technical, and what to do about it if you are.

What “end of life” actually means

Three words get used loosely and mean quite different things, so it is worth being precise before you go asking anyone questions.

• Deprecated means: still works, still supported, but the makers have told you it is on the way out. This is a warning, not a problem. You have time.
• End of life means: the makers have stopped. No security patches, no bug fixes, no updates when the world around it changes. It still runs.
• Shut down means: the thing was a service, and the service has been turned off. This one does break, on a specific date, and there is no version of waiting that helps.

Most of what follows is the middle category, which is the one people underestimate, because nothing visible happens on the day.

What it costs you when nobody is maintaining your software

Not in the abstract. These are the four ways it actually shows up, roughly in the order you tend to meet them.

Security fixes stop, but attackers do not. When a vulnerability is found in a supported framework, a patch appears and you install it. When one is found in an unsupported framework, it is published, discussed, added to automated scanning tools, and never fixed. The knowledge spreads and the defence does not. This is the risk that matters most and the one that is hardest to see, because nothing about your app looks different.

The app stores raise the floor every year. Apple and Google both require apps to target a recent SDK, and they lift that requirement annually. An app nobody has touched keeps working for people who already have it, then one day fails review on a small routine update. Now you cannot ship anything, including the urgent fix you were trying to ship, until the whole thing is brought forward. We wrote more about how this catches people out in when software ships faster than anyone can check it.

Finding people gets harder and more expensive every year. Every year a framework is unsupported, fewer developers know it and fewer want to. The ones who do can charge more, and they are right to. You are not just paying for the work, you are paying for the shrinking pool.

The things it connects to move without you. Your software talks to payment processors, mapping services, login providers and analytics tools. Those keep changing. Supported frameworks get updated to keep up. Unsupported ones do not, so one day a integration simply stops, and the fix is no longer a small one.

The ones we keep finding in production

These come up often enough in real codebases to be worth naming, with the dates their makers actually announced.

Xamarin reached end of support on 1 May 2024

Microsoft ended support for Xamarin and Xamarin.Forms entirely. No security patches, no fixes, nothing. Plenty of business apps were built on it, and most of them still run.

The supported successor is .NET MAUI, and it is a genuine successor rather than a rewrite from scratch: much of the structure and a good deal of the C# carries across. If your team is a .NET team, that is almost certainly the path. If the app is small, or you were unhappy with it anyway, this is a fair moment to ask whether Flutter or React Native would suit you better. That question is mostly about who maintains the app afterwards, not about which framework is best.

AngularJS support ended in January 2022

Worth being clear, because the names cause real confusion: AngularJS is version 1, and it is finished. Angular, without the JS, is the modern one and is alive and well. If your team says “we use Angular”, that could mean either, and the difference is several years of security patches.

Moving off AngularJS is usually a rewrite of the front end rather than an upgrade, which is unwelcome news but better known early. The destination is a normal choice between modern Angular, React and Vue, and the deciding factor is again your team rather than the technology.

Vue 2 reached end of life on 31 December 2023

Vue 2 still installs and still runs, and receives nothing. The path to Vue 3 is better than the AngularJS situation, because there is an actual migration route and a compatibility build, but it is still a real project rather than a version bump. Commercial extended support exists from third parties if you genuinely need to buy time, which is a reasonable stopgap and an expensive permanent home.

Firebase Dynamic Links shut down on 25 August 2025

This one is in the third category. It was a service, and Google turned it off. If your app used Dynamic Links for the links that open the app in the right place, or for tracking which campaign brought a user in, those links stopped working rather than degrading quietly.

The replacements are Apple's Universal Links and Android App Links, which are the platform features underneath, or a commercial deep linking service if you want the attribution reporting too. If you are unsure whether your app used it, that is a five minute question for whoever maintains it and worth asking today.

InVision shut down at the end of 2024

The design collaboration platform closed. Practically, most teams had already moved to Figma. The part that catches people is not the tool, it is what was inside it: prototypes, comments, and the record of why an interface ended up the way it did. That history is easy to lose without noticing, and impossible to reconstruct later.

Adobe XD is in maintenance mode

Adobe has not announced an end of life date, so this one is less urgent than the others. But XD is no longer sold as a standalone app and is not receiving new features. It is a tool in slow decline rather than a dead one, which means you can plan calmly, and should.

Summary: what to move to

How to check your own software without being technical

You do not need to read any code. Send whoever maintains your software these three questions and read the answers carefully.

1. What frameworks and libraries does our app depend on, and what version is each one? Version numbers are the whole point. An answer without them is not an answer.
2. When were those last updated? Not when the app was last changed. When the things underneath it were last brought forward. These are different dates and the gap between them is the thing you are measuring.
3. Is anything we depend on past end of life? Direct question, direct answer. It is public information and it takes an afternoon to check.

A team that has been keeping up answers within a day, in detail, without defensiveness. Vagueness, delay, or an answer that talks about the app rather than its dependencies is itself the finding. If nobody can answer at all, which happens more often than you would expect when the original developer has moved on, an independent software audit will answer it for you in writing.

What to do about it, in what order

The instinct on reading a list like this is to fix everything. Do not. Migrating everything at once is how these projects turn into the disaster they were meant to prevent. Sequence by risk instead.

First, anything touching money, personal data or logins. That is where an unpatched vulnerability actually costs you something, and it is the only part of this list that is genuinely urgent.

Second, anything blocking a release. If you cannot ship an update to your app, everything else is stuck behind it, including work that has nothing to do with any of this.

Third, the slow decline. Design tools, internal utilities, things with no path to a customer. Real, worth planning, not worth an emergency.

And be honest about what does not need doing. Software that is merely old, still supported, still patched and working fine is not a problem, and replacing it because it feels dated is a way to spend a lot of money on nothing. Old and unsupported are different words. Only one of them is a reason to act.

The uncomfortable part

Almost everyone reading this already suspects the answer for their own software. The reason it goes unchecked is rarely ignorance. It is that finding out means hearing something expensive, and the software is working right now, and there is always something more pressing this quarter.

That reasoning holds for a surprisingly long time, and then it stops holding all at once, usually on the day you urgently need to ship a change and discover you cannot. The cheapest version of this problem is the one you go looking for. The expensive version is the one that finds you.

If you want a straight answer about what you are running on, we do independent software audits: a fixed fee, a written report you keep, and a recommendation that is yours to take anywhere, including to somebody else.