An app doesn't have to be old to stop working
Most mobile apps don't stop working because someone broke them. They stop working because they fell behind: behind store requirements, operating system versions, libraries and the people who knew them. The symptoms only surface when something needs to ship. Suddenly the update fails review, the project won't compile on a new laptop, and nobody has seen the signing key in two years.
This article is a practical checklist. Fifteen points you can check yourself, with no audit and no consultation, and in most cases in a single afternoon. For each one we tell you exactly where to look and what counts as a red flag.
At the end you'll find a simple scoring system and a guide to reading your result. If you're after the wider context, we described the symptoms of a neglected app in 5 signs your mobile app is quietly dying. Here we stick to specifics you can tick off.
Part 1. Platform and store compliance (points 1–4)
This is the only part of the list where neglect leads to a hard block. It's not "it'll get harder", it's "you won't ship the update".
1. Does targetSdk meet the current Google Play requirement?
Every year Google Play raises the minimum API level that new and updated apps must target. The deadline usually falls at the end of August or early September and covers the Android version from the previous year. After that date you can't upload a new version of an app that targets an older level.
Where to check: the targetSdk value (formerly targetSdkVersion) in app/build.gradle.kts or app/build.gradle. Google Play Console itself shows the current required level and deadline: if your app is below the threshold, it displays a warning with the date.
Red flag: a targetSdk below what the store requires, or one that nobody on the team can quote from memory.
A word of caution: raising targetSdk is not a matter of changing one number. Each API level brings new restrictions on file access, permissions, background work and foreground services. It's real development work, and it's far better spread across quarters than done in a panic two weeks before the deadline.
2. Is the app built with the current iOS SDK?
Apple has a similar rule: apps submitted to the App Store must be built with the latest public SDK. The requirement usually kicks in during spring, a few months after the new OS version is released.
Where to check: the Xcode version on the build machine and in the CI configuration, and the IPHONEOS_DEPLOYMENT_TARGET value in the project settings.
Red flag: the project needs a specific older version of Xcode because "it won't compile on a newer one". That means a block on your next release is only a matter of time.
3. Are your privacy declarations and compliance requirements up to date?
Both platforms now require data declarations: the Data safety section on Google Play and privacy labels on the App Store. On iOS you also need privacy manifests for libraries that use certain APIs. On top of that come accessibility requirements. The European Accessibility Act has applied since June 2025, and for many digital products it means meeting WCAG 2.2 at level AA.
Where to check: App Store Connect → privacy section; Play Console → Data safety; the privacy policy linked in both stores.
Red flag: the declaration hasn't been updated since a new integration was added, such as analytics, an advertising SDK, payments or third-party sign-in. A declaration that doesn't match reality is grounds for rejecting an update.
4. Does the app work properly on the latest operating systems?
Here's a simple test that surprisingly often nobody has done. Install the production version from the store on a phone running the latest iOS and one running the latest Android, then walk through the three main user journeys.
Red flag: anything that looks different from how it should: truncated text, overlapping elements on screens with a notch, unhandled gestures, permission prompts at the wrong moment, no support for dark mode. An app doesn't suddenly "stop working". First it starts to look abandoned.
Part 2. Code and dependencies (points 5–7)
5. How many dependencies are out of date?
Where to check. It takes one command, depending on your stack:
# Android (with the ben-manes/versions plugin)
./gradlew dependencyUpdates
# Flutter
flutter pub outdated
# React Native / Node
npm outdated
# iOS
pod outdated
Red flag: more than a handful of dependencies a whole major version behind, or any library with no release in two years that isn't a deliberately chosen, stable dependency.
What matters here is how the cost grows. Updating every quarter takes a few hours. Updating after two years means jumping several major versions at once, each with its own breaking changes. The cost doesn't grow linearly.
6. Are there known vulnerabilities in your dependencies, or secrets in your repository?
Here are two scans worth running on the same evening.
Where to check:
npm audit # Node / React Native
./gradlew dependencyCheckAnalyze # OWASP Dependency-Check
gitleaks detect # secrets across the entire Git history
Red flag (vulnerabilities): anything rated high or critical in a dependency used in production. Watch networking, cryptography, data parsing and image handling libraries most closely. A separate red flag: nobody knows whether this kind of scanning runs at all. The cheapest fix is to switch on Dependabot or an equivalent in the repository, which does it automatically.
Red flag (secrets): an API key, connection string or token in the code or in a committed .env file. The crucial thing to understand: deleting a secret in a later commit doesn't remove it. It stays in the Git history. A live secret you find needs rotating immediately, because you have to assume it has leaked. This problem has grown noticeably in projects built with AI assistants, as we described in our article on AI-written code in production.
7. Are the framework and language on a supported version?
This matters most for cross-platform projects, where things change faster than in native ones. In practice, React Native and Flutter support only a narrow window of recent versions. Older ones get neither security fixes nor compatibility with new operating systems.
Where to check: flutter --version, the react-native version in package.json, and the Kotlin or Swift version in the project configuration.
Red flag: a framework version more than a year old. If you're facing a bigger migration, it's also a good moment to rethink the technology choice itself. You'll find a comparison in Flutter vs React Native vs Kotlin Multiplatform.
Part 3. Stability and data (points 8–10)
8. What is your crash-free rate?
Where to check: Google Play Console → Android Vitals; App Store Connect → Metrics; Crashlytics or Sentry, if they're set up.
Healthy value: above 99.5% crash-free sessions, and practically 100% on critical paths such as sign-in, payment and placing an order. Google Play treats stability as a distribution factor. Exceeding its bad behaviour thresholds (roughly 1.09% user-perceived crash rate) can limit your app's visibility in the store.
Red flag: you don't know your number. That's worse than a bad number, because at least someone is looking at a bad number.
9. What are your ANR rate and app start-up time?
On Android, ANRs (Application Not Responding) can do more damage than crashes, because to the user they look like the phone has frozen. Google Play applies a separate threshold, roughly 0.47% of sessions.
Where to check: Android Vitals → ANR rate and start-up time (cold start). For iOS: App Store Connect → Metrics → Launch Time.
Red flag: a cold start longer than 2–3 seconds, or an ANR rate that has been climbing over recent releases. A common cause is synchronous network calls or heavy SDK initialisation at launch. The problem usually sits in the backend and API, not in the app itself.
10. Do you know how many active users you have, and does anyone act on the monitoring?
A tool that collects data nobody looks at isn't monitoring. It's an archive.
Where to check: product analytics (Firebase, Amplitude, whatever you use), Play Console → Statistics, App Store Connect → Analytics. Compare the number of installs with the number of active users over the last 30 days. Also check whether alerts about rising crashes go to a channel someone actually reads, and whether there's a named person responsible for reviewing the metrics.
Red flag: no analytics at all, a gap between what the company assumes and what the data shows, or alerts going to a shared inbox that everyone has muted. A gap in the data is the most common surprise in our audits, and it works both ways. Sometimes an app written off as "unused" has a stable group of loyal users who would really feel it if the service were switched off.
Part 4. Development process (points 11–12)
11. How long does a build take, and could you ship a release today?
Two questions that together tell you how healthy the project is.
Where to check: measure the time of a full release build (./gradlew --profile assembleRelease; in Xcode, Product → Perform Action → Build With Timing Summary) and how long the CI pipeline takes to run.
Healthy value: an incremental build under a minute, and a full build with tests on CI within a few minutes.
Practical test: ask the team to ship a release that changes one word in the interface. If the answer is "we'd first need to check whether it even builds", you don't have a working release process. You have an archaeological dig.
Red flag: the build takes over ten minutes and nobody sees that as a problem, or the project only builds on one specific machine.
12. Are there tests, and does anyone run them?
This isn't about a coverage percentage. It's about whether there's a safety net under the paths that would hurt most if they broke.
Where to check: whether the tests pass (./gradlew test, flutter test, npm test), whether they run automatically on every pull request, and whether they cover sign-in, payments and saving data.
Red flag: tests exist but are switched off "because they kept breaking". That's worse than having none, because it gives a false sense of security. Another version of the same problem: tests that only check mocks and pass even when the logic is wrong.
Part 5. Continuity and control (points 13–15)
This is the shortest part of the list, yet a single gap here can bring the whole product to a halt. You need to answer these three questions with names, not "probably someone in IT".
13. Who owns the store accounts, and who reads their emails?
Does the company own the Apple Developer account and the Google Play Console account, or do they belong to an agency or a former employee? Is the contact address monitored by someone who still works for you? An Apple Developer membership renews every year. If it lapses, your app disappears from the store, and the warnings go only to that address.
Where to check: App Store Connect → Users and Access (who holds the Account Holder role); Play Console → Users and permissions.
Red flag: the owner role is assigned to a personal mailbox, an external agency's account, or an address nobody logs into.
14. Where are the signing keys, and when do the certificates expire?
On Android: does the app use Play App Signing or a local keystore? If it's local and the file goes missing, you'll never be able to ship another update to the existing app. You'd have to publish a new store listing and lose all your ratings, reviews, search ranking and install history. On iOS: where are the distribution certificates, when do they expire, and who has the permissions to renew them?
Where to check: Play Console → Setup → App integrity (whether Play App Signing is enabled); Apple Developer → Certificates, Identifiers & Profiles → expiry dates.
Red flag: the keystore is "somewhere on the drive" of a former developer, nobody remembers its password, and there's no backup in the company's secrets manager.
15. How many people can build and release this app?
This is the classic bus factor. The question is specific: how many people could, today, on a clean machine, clone the repository, build a production version and submit it to the store?
Where to check: the README in the repository. If it doesn't explain how to run the project and how to ship a release, that knowledge lives only in someone's head.
Red flag: the answer is "one person". That's a single point of failure that isn't technological. It's also the only item on this list you can't fix by throwing money at it in an emergency.
Scoring: add up your answers
Give yourself 1 point for every item without a red flag. Maximum: 15.
Score What it means What to do 13–15 The app is being maintained. The risk for 2027 is low. Keep the rhythm: a release every quarter, a metrics review every month. 9–12 There's a backlog, but it's under control. Plan one "maintenance sprint": dependencies,targetSdk, monitoring.
5–8
The app is drifting. Every change is already getting more expensive.
A technical audit and a prioritised remediation plan before the next platform deadline arrives.
0–4
There's a real risk you won't be able to ship the next update.
Start with part 5: recovering access and keys. Without that, the rest is pointless.
One note on reading the result: the points don't carry equal weight. Having no access to the signing key (point 14), or a targetSdk below the requirement a month before the deadline (point 1), are blocking problems. They outweigh five points from the dependencies section. If either of these two came out badly, treat it as the priority whatever your total.
The order to fix things in
If the list turned up more than you expected, don't start with the most technically interesting problem. Here's the order that works in practice:
- Regain control (points 13–15). Accounts, keys, contact addresses, access to the repository and CI. It's cheap and quick, and everything else depends on it.
- Remove platform blockers (points 1–3). These have hard deadlines set from outside, and no amount of negotiation will move them.
- Turn on measurement (points 8–10). Without data, every decision after this is guesswork.
- Shorten the feedback loop (points 11–12). Builds and tests multiply the cost of every future change.
- Only now tackle dependencies and technical debt (points 5–7). By this point you know what is a real risk and what merely looks old.
What it costs to keep an app maintained
Regular maintenance of a mobile app realistically costs 15–20% of the original build budget per year. There's more on how those costs break down in How much does a mobile app cost in 2026. That budget covers most of the items on the list above: quarterly releases, dependency updates, responding to platform requirements and metrics reviews.
Putting this spending off isn't a saving. It's deferring the payment, with interest. A project neglected for two years needs several weeks of work up front before you can add anything to it at all.
Summary
The question in the title, whether your app will survive 2027, really comes down to one thing: can you release it again? Not "does it work", because it may keep working for a long time. What matters is whether you can respond in days rather than quarters when a new store requirement, a critical bug or a business opportunity comes along.
All fifteen points come down to three things: platform compliance, measurability and the ability to release. Everything else matters, but it comes second.
At Mobilesoft we go through a list like this at the start of every project we take over. The result is a prioritised plan, not a list of complaints. If you'd like someone to do it for you and tell you plainly what is a blocking risk and what can wait, we handle that as part of our audits and consulting. You can also see how we approach building and maintaining mobile apps, browse our case studies or go straight to getting a quote.
And if you just want a second opinion on your score, get in touch. We'll go through the list together.