Nobody sends the email
Apps almost never announce that they are finished. There is rarely a farewell post or a shutdown notice. The app simply stops changing, and then one day it stops working properly, usually right after an operating system update.
By that point you have two years of records inside it.
The frustrating part is that this is nearly always visible in advance. Not certain, but visible. The signals sit on the store listing where anyone can read them, and almost nobody does, because the store is designed to help you install things rather than evaluate them.
Here are seven checks. They take about five minutes and they use only what the listing already shows you.
1. When was it last updated
The most obvious signal, and still the one people skip.
Every store listing shows an update date. Open it before you install anything you intend to rely on.
There is no universal cutoff, but there is a floor enforced by the platforms themselves. Google Play requires apps to target a reasonably recent Android API level to remain discoverable to new users, and Apple has a similar policy. This forces roughly annual maintenance on any app that wants to stay listed.
The practical consequence: an app untouched for two years is not merely stale. It is on a path to being hidden from new users, which usually means the developer has stopped caring whether new users find it.
Rough guide: under six months is healthy. Six to twelve is normal for a stable, finished tool. Twelve to twenty-four is a question worth asking. Beyond twenty-four, assume abandoned until proven otherwise.
2. What the updates actually say
This is the check that separates real maintenance from life support, and it is where most people stop too early.
A recent update date proves only that a file was uploaded. It says nothing about whether anyone is developing the product. Compliance updates are extremely common: the developer bumps the target API level so the store does not delist them, changes nothing else, and ships it.
Read the release notes for the last four or five versions.
Healthy looks like: specific changes. A feature named. A bug described. A platform version mentioned. Occasional notes admitting something was broken.
Life support looks like: "Bug fixes and performance improvements," repeated verbatim across every release for a year. That phrase is not always a red flag, plenty of good developers are lazy about release notes, but five consecutive identical notes is a pattern, not laziness.
If you read four updates and cannot tell what changed in any of them, you are looking at a listing being kept alive rather than a product being built.
3. Are reviews still arriving
Sort the reviews by most recent. Not by helpful, by recent.
You are not reading them for sentiment here. You are checking the dates. An app whose most recent review is fourteen months old has effectively no active users, regardless of how many total reviews it has accumulated.
This matters more than the star rating, which we covered in app store ratings are broken. A rating is a historical average and lags reality badly. Review recency is a live signal, and it is much harder to manipulate.
No users means no revenue. No revenue means nobody is being paid to keep the thing working. The rating can stay at 4.6 for years after the last person stopped caring.
4. Does the developer have anything else
Tap the developer name on the listing. You get their other apps.
Three patterns, and they mean different things.
Several apps, all recently updated. Best case. This is a going concern with a maintenance habit, and your app benefits from the same release process as the rest.
Several apps, all stale. Worst case. The developer has moved on from everything, not just this one. One stale app is a choice. Six is a departure.
One app, and this is it. Genuinely ambiguous. It might be someone's whole business, which is the most reliable maintenance incentive there is. Or it might be a side project that ended when its author got a new job. The other checks resolve which.
5. Do the permissions match a maintained app
Open the permissions and data safety section.
You are looking for permissions that no longer correspond to anything in the app. Leftover permissions from a removed feature are a small but real sign that nobody has audited the codebase in a long time, because a maintained app tends to shed permissions it stopped needing.
More usefully, this is where you find out whether an abandoned app is also a liability. An unmaintained app with broad data access is worse than an unmaintained app with none, because the code is not receiving security updates while still holding access to your contacts, location, or files. Our breakdown of how to read that section is in app permissions explained.
6. Is there a way to leave
This is the most important check on the list, and the reason is simple: it is the only one that protects you when you are wrong about all the others.
Before you put two years of data into something, find out whether you can get it back out. Look for an export, a backup file, a sync option, or a documented file format.
You are not looking for a promise on a marketing page. You are looking for a button.
If the data is stored locally and there is no export, the data is trapped the moment the app stops opening. If the data is on someone's server and there is no export, it is trapped the moment they stop paying for the server. We wrote about what that actually looks like in what happens to your data when an app shuts down.
An app with a clean export is a low-risk bet even if it dies. An app without one is a high-risk bet even if it thrives.
7. Does the money make sense
Last check, and the one that predicts the others.
An app needs a reason to keep existing. Ask what pays for the next two years of maintenance:
A subscription aligns reasonably well. Someone is being paid monthly to keep it working, and losing you costs them.
A one-time purchase funds development but not maintenance indefinitely. It works when the app is genuinely finished and the developer treats it as an asset rather than a project.
Advertising funds it as long as usage holds up. When usage falls, the maintenance falls first.
Nothing visible means the funding is unresolved, and unresolved eventually resolves, usually into advertising, a subscription, or a shutdown. Free with no model is not free, it is undecided. We covered all six funding models in how free apps actually make money.
Cross-subsidy, where the app supports some other business, is the sneakiest case. It is well funded right up until the parent company reorganises, and then it is a line item.
The five minute version
Store listing, in order:
- Update date. Older than two years, stop here.
- Last four release notes. Can you tell what changed in any of them?
- Sort reviews by recent. Are people still turning up?
- Tap the developer. Is anything else of theirs alive?
- Permissions. Anything there that no feature explains?
- Search the app's own settings or website for "export".
- Ask what pays for it.
Any single failure is survivable. Three or more is a pattern, and the pattern is reliable enough to act on.
The awkward part
We build apps, so applying this list to ourselves is only fair.
PackPilot and PawDex are both free on Google Play with no advertising, no in-app purchases and no subscription. By check seven, that is the unresolved category, and by our own advice you should weigh that rather than wave it away.
The stated intention is a paid tier once each app has enough users to support one, rather than advertising. But an intention is not a funding model, and you should treat it as exactly the kind of claim this article tells you to discount.
What you can actually verify: the update dates and release notes on the Play listings, which is the check we would run on someone else. Do that instead of taking our word for it. This is the same reason we keep writing about how to leave software rather than only how to choose it, which we set out in how to choose an app you will still use in a year.
Why this keeps happening
Worth understanding the mechanism, because it is not usually neglect.
Most apps are not abandoned by a decision. They are abandoned by arithmetic. The revenue no longer covers the maintenance, the developer takes a job, the startup pivots, the acquiring company shuts the product line. In almost every case the app keeps working for a while afterwards, which is precisely what makes it hard to notice.
The end state is rarely dramatic. An OS update changes something, the app breaks in a small way, nobody fixes it. Then another. The app degrades over months rather than failing on a specific day, which is related to but distinct from the pattern in why apps get worse over time: there, someone is still working on it and making it worse. Here, nobody is working on it at all.
Both end in the same place. Only one of them gives you a warning.
The short version
Abandonment is predictable, and the evidence is on the listing.
- Update date under six months is healthy, over two years is finished
- Release notes that never say anything specific mean compliance, not development
- Recent reviews prove there are still users, which is what funds maintenance
- Check the developer's other apps, one stale app is a choice and six is a departure
- Unmaintained plus broad permissions is worse than unmaintained alone
- An export button is the only check that protects you when the others are wrong
- No visible funding model means undecided, not free
Related Reading
- How to Choose an App You Will Still Use in a Year is the wider version of this checklist.
- What Happens to Your Data When an App Shuts Down covers what to do once it has actually happened.
- App Store Ratings Are Broken explains why review recency beats the star rating.
- How Free Apps Actually Make Money covers the funding models behind check seven.
- App Permissions Explained covers reading the data safety section properly.
- Why Apps Get Worse Over Time covers the opposite failure, where someone is still working on it.
- How to Tell If an App Will Cost You Money covers the other half of the pre-install check.
Sources and further reading: Google Play target API level requirements, Apple App Store review guidelines, Google Play Data safety section.
Frequently Asked Questions
Check the update date on the Play listing, then check what the updates actually say. An app updated within the last six months with release notes describing real changes is maintained. One updated eighteen months ago, or updated recently with notes that only say bug fixes and performance improvements for the fifth time running, probably is not.
There is no fixed number, but both stores enforce a floor. Google Play requires apps to target a recent Android API level to stay visible to new users, which forces roughly annual maintenance. An app that has not been touched in two years is either abandoned or about to be delisted, because it will fail that requirement.
Not on its own. Compliance updates exist purely to satisfy store requirements and change nothing for you. The tell is the release notes: if several consecutive updates say nothing specific, the developer is keeping the listing alive rather than developing the product.
It depends entirely on whether the app stores data on your device or on a server. Local data usually survives until you uninstall, but becomes unreachable without the app. Server-stored data disappears when the servers do, often with limited notice. This is why checking for an export function before you commit matters more than any other single check.
Low volume is not the signal. What matters is whether reviews are still arriving. An app with 300 reviews of which the most recent is fourteen months old has effectively no users, and no user base means no revenue and no reason for anyone to keep maintaining it.
No, and some of the most durable software is made by one person. The relevant question is not team size but whether the app has a funding model that survives the developer losing interest, and whether you can get your data out if it does. A paid app from a solo developer with a clear export is often safer than a free app from a startup.