How often should you update your app: what the data says

How often you should update your app

Every 90 days is the cadence I'd defend, and I want to be upfront that this is a judgement call rather than something the data below proves. The data tells you where the herd sits and what staleness correlates with. It does not contain a controlled experiment on release frequency, and nobody's does.

The 90-day number comes from three constraints that are external to your roadmap: OS releases land roughly annually on both platforms and break things unevenly, both stores raise the minimum target API level on a rolling annual schedule with a published cut-off date each year, and Apple removes apps not updated in three years under its App Store Improvements programme. Ninety days gives you four shots a year at staying ahead of all three.

180 days is the line where it stops being an engineering question and becomes a perception one. That's where a user checking your listing sees a last-updated date old enough to wonder whether anyone's home.

How stale the average app actually is

Across 6,634 audited Google Play and App Store listings, one in five hasn't shipped anything in six months.

• The rows nest. Every app in the 730-day row is also counted in the 365-day and 180-day rows.
• 79.8% is simply 100% minus the 180-day figure.
• The dashes are honest gaps. Those cells weren't queried, and showing the hole beats computing a number the query never returned.

The counterintuitive finding: fresher apps show more complaints

Look at the right-hand column again. 65.8% of apps updated within the last six months carry a complaint cluster, against 47.7% of apps that have been stale for over a year. The actively maintained apps look worse.

The lazy version of this article says stale equals broken, puts a scary chart under it, and sells you a maintenance retainer. The data doesn't support that, so I'm not going to write it.

This is not evidence that shipping updates creates bugs. It's mostly a measurement artifact, and understanding which artifact matters, because it changes what you should do with the number.

Three reasons the fresher apps look worse

First, detection needs reviews. A cluster requires at least two 1-to-3-star reviews using the same complaint language on the same listing. An app nobody has opened in a year collects nothing to classify. Its silence gets scored as health when it's really absence — the average audited app draws 40.4 reviews a month, and an abandoned one draws a fraction of that.

Second, live apps have more users. Apps that ship are, on average, apps someone is still promoting, still ranking, still acquiring installs for. More users generate more edge cases, more devices, more payment attempts, more of everything that turns into a review.

Third, the stores surface recent reviews. Both return a slice weighted toward recent and relevant, not the full archive. An app whose last real user activity was in 2024 presents a thinner, older review sample — so even its genuine problems have partly aged out of view.

Put together: a low cluster count on a stale listing is weak evidence of quality and strong evidence of quiet. If you're evaluating an app to buy, a stale listing with no clusters should raise your suspicion, not lower it.

What update frequency actually buys you

Not fewer complaints, on this evidence. What it buys is the right to stay in the store and stay compatible.

Google Play's target API level requirement is the sharpest of these. Play raises the minimum target API level on a rolling annual schedule, with the level and the cut-off date for each year published on Google's target API page. Fall below the current floor and the app stops being available to new users on newer devices. An app that stops shipping doesn't get a warning shot on this — it gets narrowed distribution.

Apple's App Store Improvements programme removes apps that haven't been updated in three years and fall below a minimal download threshold over a rolling twelve months. Developers get an email and 90 days to ship something. Apps that crash on launch are removed immediately, with no notice period.

Neither store documents release frequency as a search ranking factor, and I'm not going to claim it is. What both document is the removal and distribution machinery above, which is a harder consequence than a ranking nudge anyway.

What counts as a meaningful update

A version bump with "bug fixes and performance improvements" in the release notes satisfies the calendar and nothing else. Since 4.6% of the audited catalog (302 apps) is already past two years stale — within a year of Apple's removal window — plenty of teams have discovered that a token release doesn't fix what made them stop shipping in the first place.

The updates worth counting do at least one of these:

• Raise the target SDK or minimum OS to keep distribution intact.
• Close the top complaint cluster on your listing — payment, device compatibility and UI or UX are the three most common across the catalog.
• Add or fix support for a device class or screen size users are actually complaining about.
• Ship something a user would notice and describe to another person.
• Refresh the store listing itself: screenshots, short description, what's-new text. It costs no engineering time and it's the part users read.

Signs an app is no longer maintained

These are the signals visible from the store page alone, which is all you get when you're assessing someone else's app. None is conclusive by itself; three together usually are.

• Last update over 365 days ago. That's 9.4% of the audited catalog (622 apps). Over 730 days is 4.6% (302 apps) and is close to terminal.
• No developer replies, ever. 47.4% of audited apps (3,143) have never replied to a single review. Against an average reply rate of 28.0%, a permanent zero is a strong tell.
• Release notes that haven't changed in years. The same "minor bug fixes" string across five versions means the release is automated or cosmetic.
• Complaint clusters with no corresponding release. A payment cluster that's been accumulating reviews for eight months with no update behind it is the clearest abandonment signal there is.
• A store listing frozen in an older design era. Screenshots showing a UI two OS generations old means nobody has opened the console with intent.
• Review velocity collapsing. Against a catalog average of 40.4 reviews a month, a listing that's dropped to near-zero has lost its user base, not just its developer.

Is this app abandoned? A five-minute check

If you're buying an app, using one for something that matters, or auditing a portfolio you inherited, run these in order. It takes about five minutes per app.

• Check the last-updated date against the 180 / 365 / 730-day bands in the table above. That gives you the cohort.
• Read the last 20 reviews rated 1 to 3 stars. Look for the same complaint appearing twice — that's the cluster bar.
• Check whether any of those reviews got a developer reply, and how recently.
• Compare the newest complaint date against the last release date. Complaints newer than the last ship, with no ship since, is the abandonment pattern.
• Check the developer's other apps. A studio that let one listing rot has usually let the whole portfolio rot — and in this catalog that pattern repeats often enough that it's how we find new apps to audit.

What this data can't tell you

It's correlational. I can show you that recently updated apps carry more complaint clusters than stale ones. I cannot show you that updating causes complaints, and I've argued above that it almost certainly doesn't — the mechanism is detection bias.

Installs, retention and revenue aren't in here. They live in the developer console, they aren't scrapeable, and estimating them would undermine everything else on this page.

The catalog is not a random sample of the stores. Apps enter through keyword search, similar-app rails, developer portfolios and top charts, and Games are deliberately excluded. Every figure above is a snapshot of the audited catalog taken on 3 August 2026; the catalog grows continuously, so the live totals are higher, and the staleness bands shift every day by definition.

For the detection method in full, see /methodology. To check the maintenance signals on one specific listing rather than the aggregate, /app-audit runs the same checks, and /app-reports holds the audited catalog.