5 signs your mobile app is quietly dying

Mobile apps rarely die with a bang

There is no single day when an app stops working. No "project closed" alert, no outage that makes someone call a crisis meeting. An app dies gradually and quietly — over a year or more, while everyone is busy with more important things.

We know this scenario from our audits. The call usually goes like this: "We have an app, it works, but we'd like to add one feature." We open the repository and discover that adding that one feature first requires three months of work, because the project won't compile in any modern environment and half of its libraries are no longer supported.

Below are the five signs we see most often in projects like these. They are not abstract "best practices" — they are concrete symptoms with concrete consequences. If you recognise two or more in your own app, it has probably already reached the stage where the cost of fixing it grows faster than the value it delivers.

Sign 1: the last release was more than a year ago

This is the easiest sign to check — just open the App Store or Google Play and look at the date of the last update.

No releases for 12 months does not mean the app is "finished and stable". It means that for a year the world around it has changed, and the app hasn't:

• a new major version of iOS and Android has shipped, and nobody has checked whether the app behaves correctly on them;
• screen resolutions and aspect ratios have changed in new phone models;
• the libraries the project depends on have received security updates — which were never applied;
• backend integrations (payments, maps, sign-in, push notifications) have changed their APIs or retired old versions.

The worst part is invisible: every month without a release raises the cost of the next one. A project that updates its dependencies every quarter does it in a few hours. A project that hasn't done it for two years needs to migrate across several major versions at once — each with its own breaking changes. The extra work doesn't grow linearly; it grows exponentially.

A practical test: ask your team to ship a version that changes one word of text. If the answer is "we'd first need to check whether it even builds" — you have your answer.

Sign 2: the crash rate is rising and nobody is looking

The second sign is insidious, because the data usually is there — nobody just looks at it. Google Play Console has an Android Vitals section, App Store Connect has stability metrics, and the project often contains a forgotten Crashlytics or Sentry setup. The problem is that it isn't anyone's job.

Why this matters for the business, not just for the engineers:

• Google Play treats stability as a ranking and distribution factor. Exceeding the bad behaviour thresholds (roughly 1.09% of sessions with a user-perceived crash and roughly 0.47% with ANRs) can trigger a warning in the console and reduced visibility of the app in the store.
• After the second crash, a user usually doesn't report the bug. They uninstall the app and never come back. You won't see it in support tickets — you'll see it in retention, several months later, when it's hard to link cause and effect.
• A rising crash rate with no new releases almost always means the app is starting to drift out of step with new OS versions. It's a leading indicator, not a lagging one.

A healthy benchmark for a production app is more than 99.5% crash-free sessions, and for critical paths (sign-in, payment, placing an order) — practically 100%. If you don't know your number, that is the symptom: it's not that the number is bad. It's that it doesn't appear in anyone's reports.

Sign 3: the only developer who knew the project has left

Management literature calls this the bus factor — how many people would have to disappear from the team for the project to grind to a halt. When the answer is "one" and that one person has already left, the bus factor is zero. The project is formally alive, but nobody actually knows anything about it.

What exactly leaves along with that person:

• Architectural decisions with no rationale in the code. Why is there a custom cache implementation instead of a library? Because the library had a bug three years ago? Because someone didn't know the library existed? Nobody knows, so nobody dares touch it.
• Operational knowledge. Where the build server lives, what the release process looks like, what has to be done by hand before shipping a version, which flag to set in the production configuration.
• Product context. Why does this screen look so odd? Because the client wanted it that way, or is it a workaround for an API problem?

The effect is measurable: every change turns into an investigation. A new developer estimates a three-day task at two weeks — and they're right, because twelve days go on reading code and one on the change itself. The team starts avoiding risky areas, wrapping them in yet more special cases instead of fixing them, and the debt keeps growing.

A contingency plan almost nobody has prepared: do you know who has access to the developer account, the signing keys and the repository? In projects where the only developer has left, the answer is surprisingly often "I think he does". More on that separately in a moment.

Sign 4: the build takes 15 minutes — or nobody knows how to run it

A fifteen-minute build looks like a minor inconvenience. In practice it is a multiplier for every other problem.

Let's do the maths honestly. A developer fixing a bug goes through the "change → build → check" loop a dozen or more times a day. At 15 minutes per build, that's 2–4 hours a day of waiting. But the consequences aren't purely arithmetic — the way people work deteriorates:

• people stop testing locally, because it takes too long, and push changes straight to CI "to see if it works";
• changes become bigger and less frequent, because if you have to wait anyway, you may as well push five things at once — and bigger changes are harder to review and break things more often;
• tests stop being run, because they would make the loop even longer;
• fixing a critical production bug takes half a day instead of an hour, no matter how simple the fix itself is.

The extreme version, which we also come across: the build doesn't work at all on a new machine. The project needs a specific old version of Xcode or Android Studio, a specific Java version, a dependency pulled from a repository that no longer exists, and a local configuration file that isn't in the repo because "everyone has their own". Getting such a project running is a standalone, multi-day archaeological dig — before a single line of new code is written.

A healthy benchmark: an incremental build under a minute, and a full build with tests on CI within a few minutes. If you're ten times above that, it's not a matter of developer comfort — it's a real cost attached to every future change.

Sign 5: store warnings land in an inbox nobody reads

This is the sign that most often triggers a genuine crisis — and at the same time the easiest to miss, because all the communication goes by email to an address set up when the app was published four years ago. Often the address of someone who no longer works at the company.

What arrives in that inbox:

• Target API level requirements. Every year Google Play raises the minimum API level that app updates must target. After the deadline you can't ship an update, and older apps stop being shown to users on newer devices. Apple similarly requires builds made with the latest SDK.
• Compliance requirements. Privacy declarations, data collection disclosures, accessibility requirements (EAA and WCAG 2.2), consent for data processing. Failing to respond means rejected updates and, in extreme cases, removal of the app from the store.
• Expiring certificates and accounts. An Apple Developer account is paid for annually. Distribution certificates and provisioning profiles have expiry dates. An expired account means the app disappears from the store — with no warning visible to anyone except whoever owns that inbox.

The most expensive variant of this problem is losing access to the Android signing key. Without it you cannot ship an update to the existing app — you have to publish a new store listing, which means losing all your reviews, ratings and search rankings, and having to migrate users manually. Google offers a recovery procedure through Play App Signing, but only if it was set up beforehand.

A five-minute test worth doing today: check who receives emails from App Store Connect and Google Play Console, whether that person still works at the company, and when they last opened the console.

What it really costs

An app in this state generates costs that don't show up in the IT budget, because they're spread across the business:

It's worth comparing this with the cost of regular maintenance, which realistically comes to 15–20% of the initial build budget per year — more on that in our article How much does a mobile app cost in 2026. Skipping maintenance isn't a saving. It's a deferred payment at a very high interest rate.

What to do if you recognise your app

The order matters. The most common mistake is starting by building new features in a project nobody is in control of.

Step 1: regain control (days, not weeks). Gather and verify in one place: access to the developer accounts, signing keys, the repository, CI configuration, and access to the backend and integrations. Check that the contact address in both stores is up to date and actually read. This is the cheapest item on the whole list, and at the same time the one whose absence can block everything else.

Step 2: measure the actual state. Turn on or dig out crash monitoring, check Android Vitals and the metrics in App Store Connect, and establish the real number of active users. Without numbers, every further decision is guesswork — and very often it turns out the app has either far fewer or far more users than the company assumes.

Step 3: run a technical audit and cost out the options. The goal is to answer one question: is it cheaper to revive or to rewrite? The answer depends on how much of the code is maintainable, how outdated the tech stack is and whether the backend can be kept. We carry out audits and consulting precisely so that this decision is based on a review of the code, not on a hunch.

In our experience, revival usually wins if the architecture is sound and the main problems are overdue updates and a missing process. A rewrite makes sense when the project is built on unsupported technology, the code makes it impossible to introduce changes safely, or the product needs a major change in scope anyway — in which case it's worth considering a modern cross-platform approach at the same time, which lowers the cost of maintaining two platforms.

A separate note for projects developed recently mainly with the help of AI assistants: there the symptoms are often the opposite — releases are frequent, but the code has never been read with real understanding. We covered this in our article on AI-written code in production.

How not to end up here again

Keeping an app alive doesn't take a big budget — it takes regularity and clear ownership:

1. A release every quarter, even without new features. Just dependency updates and compatibility with the new OS. It's the cheapest insurance policy there is.
2. One person responsible for stability metrics. A monthly review of the crash rate and ANRs — fifteen minutes a month.
3. A calendar of platform deadlines. Target API requirements, account renewals, certificate expiries. Entered once, with automatic reminders.
4. A bus factor of at least two. At least two people who can build and release the app — plus a README that actually explains how to do it.
5. A time budget for the build. Treat build time as a product metric: if it grows, someone gets a task to bring it down.

Summary

A mobile app isn't a project with an end date — it's a product that needs a steady, if small, flow of attention. The five signs in this article — no releases for a year, a rising and unmonitored crash rate, a bus factor of zero, a build that takes many minutes and an unread store inbox — aren't separate problems. They're the same problem seen from five angles: nobody owns the app.

The good news is that the first two remedial steps — regaining access and switching on measurement — are cheap and can be done within a week. Only then can you make a sensible decision about what comes next.

At Mobilesoft we regularly take over and revive projects like these — from regaining control over releases to a full rewrite where it pays off. See how we approach building and maintaining mobile apps and backend and APIs, check out our case studies or go straight to getting a quote.

If this list has left you with an uneasy feeling about your own app — get in touch. We'll look through the repository and tell you straight whether it's still a maintenance backlog or already a project that needs rebuilding.