Most common app problems: what 6,634 audited apps show

The ranked list of the most common app problems

Here is the whole ranking — all twenty categories the classifier tracks, unsorted by opinion. Every row is a complaint cluster detected across 6,634 audited Google Play and App Store listings — 13,904 clusters in total, of which 12.5% (1,741) were high severity. 62.3% of the audited apps, 4,131 of them, carry at least one cluster.

Read the middle column as how many apps have the problem, and the right-hand column as how loud users get when they do. Payment and device compatibility finish neck and neck at the top: 28.6% against 28.4%, a gap of 0.2 points and fifteen apps. That is well inside the range a fortnight of crawling could reverse, so read them as tied rather than first and second. Crashes — the failure everyone assumes tops this list — sit seventh.

One app can sit in several rows

The columns don't add up to 6,634, and they shouldn't. An app with a payment cluster and a login cluster is counted in both rows. That's also why I won't hand you a combined "billing problems" percentage by adding payment to subscription to refund — the overlap is real and I haven't measured it, so summing those rows would invent a number.

The average audited app that has any cluster has about 3.4 of them (13,904 clusters spread over 4,131 apps). Problems travel in groups.

How these clusters were detected, and what they are not

The method, plainly: for each listing we take the public reviews the store returns, keep the ones rated 1 to 3 stars, and run keyword classification over that text. A cluster registers only when at least two reviews on the same listing match the same category. One furious review about a camera never becomes a camera cluster.

A cluster is a user-reported signal. It is not a confirmed code defect, and I'd rather say that in the third paragraph than bury it. A payment cluster means two or more people wrote that payment went wrong. It does not tell you whether the fault is in your billing code, the store's purchase sheet, a card issuer, or a trial screen the user misread.

The reviews are a sample, not the population. Both stores return a slice of recent and most-relevant reviews rather than the full archive, so a problem that stopped generating reviews two years ago is invisible here, and one that started last week may not have surfaced yet. Keyword classification also produces false positives — "love this app, no crashes" contains the word crash. The two-review minimum suppresses most of that noise. It does not eliminate it.

Every figure on this page is a snapshot of the audited catalog taken on 3 August 2026. The catalog grows continuously, so the live totals are already higher than the counts printed here; the shares move far less than the counts do.

No AI model runs anywhere in the detection path. The classification is keyword-based and free to run, which is the only reason it can be applied to every app in the catalog instead of a hand-picked hundred. The full write-up is on /methodology, and the audited listings themselves are at /app-reports.

Device compatibility is a rounding error from first, and almost nobody plans for it

1,885 apps, 7,894 matching reviews, 28.4% of everything we audited. It is second by fifteen apps, which is not a real gap, and in my experience it is the cluster teams are least prepared to hear about.

The reason is structural. Your team tests on maybe six devices. Your users have a thousand, running four OS generations, at screen ratios nobody designed for. Compatibility failures are cheap to ship and expensive to see, because the devices that fail hardest generate the fewest sessions in your analytics — a blank screen on launch doesn't log much.

The review language is distinctive once you know it: worked on my old phone but not the new one, doesn't fit my screen, tablet layout is broken, stopped working after the Android update. None of that reads as urgent in a triage queue. It should.

There's a distribution cost too. Google Play's per-device bad-behavior threshold is 8% of daily active users hitting a user-perceived crash on a single device model, and crossing it makes the app less discoverable on those devices with a warning on the store listing. A compatibility failure confined to one popular handset can cost you installs without ever moving your overall crash rate.

Payment and subscription complaints are the loudest money problem

Payment takes the top row at 1,900 apps (28.6%) and 8,170 reviews. Its lead on app count is fifteen apps and I would not defend it; its lead on review volume is 276 reviews, which is also thin. What is not thin is the money theme as a whole: subscription is fourth at 1,448 apps (21.8%) and 6,616 reviews, and refund is eleventh at 433 apps (6.5%). Three of the top eleven rows are about money changing hands.

These are the highest-leverage complaints in the table, and here's my position on why: they're the only ones written by people who already paid you. A user complaining about your onboarding is a prospect. A user complaining about a charge is a customer, publicly, on the page where your next customer decides.

Apple's App Review Guidelines are specific about the mechanics here — 3.1.2 requires that subscription duration, content and downstream charges be disclosed before purchase, and 3.1.1 requires a working restore mechanism for restorable purchases. A large share of the subscription reviews I've read describe exactly those two things failing: the restore button that does nothing on a new device, and a disclosure that is technically present and practically invisible.

The honest limit: we cannot separate a genuine billing bug from a user who forgot they subscribed. Both produce identical review text. But that distinction matters less than it feels like it should — a cancellation flow people can't find generates the same one-star review as a cancellation flow that's broken, and costs you the same rating.

UI and UX complaints outrank crashes by 2.5 to 1

1,684 apps have a UI or UX cluster (25.4%) against 686 with a crash cluster (10.3%). Users are two and a half times more likely to publicly complain about how your app is built than about it falling over.

Teams invert that priority almost universally, and the reason is boring: a crash has a stack trace and a UX complaint has an opinion. One lands in a bug tracker automatically, the other needs someone to read reviews on a Tuesday. The store rating does not make that distinction — both arrive as one star.

What these reviews say, in rough order of frequency: the new update ruined it, I can't find the button I used every day, ads sit on top of the controls, I have to sign up before I can see anything. A lot of it is change management rather than design quality.

One thing we can't tell you: whether a UX cluster followed a redesign. The stores don't expose a link between a review and the app version it was written about, so any claim that "redesigns cause complaint spikes" would be me guessing. It's a gap in the data, not a finding.

Why do apps crash, and why crash complaints only rank seventh

Crashes affect 686 apps (10.3%) with 2,307 matching reviews. Freezing is a separate cluster at 387 apps (5.8%), and slow performance at 579 apps (8.7%). Even added loosely together, that whole family lands below payment or device compatibility on its own.

Three things explain the low rank. First, crashing is the one failure mode both platforms measure directly and both stores punish, so it gets engineering attention that payment friction never does. Second, an app that crashes on launch often gets deleted without a review — the angriest users are the quietest. Third, users describe the same event in different words, and we count "it freezes" and "it's unusably slow" as their own clusters rather than folding them into crash.

The platform pressure is real and quantified. Google Play's overall bad-behavior threshold is 1.09% of daily active users experiencing a user-perceived crash, and 0.47% for user-perceived ANRs; exceed either and the app becomes less discoverable. Apple rejects apps that crash under guideline 2.1, and its App Store Improvements policy states that apps crashing on launch are removed from the App Store immediately.

So if you're prioritising from this table, crashes are the line you probably already have a dashboard for. The six rows above it are the ones nobody instruments.

What "app not working" actually means

"App not working" is not a category. It's a routing problem — the user has one phrase for five unrelated failures, and the first job for an owner is turning that phrase into one of the twenty rows above. Here's roughly what it decomposes into, by how common each cause is in the catalog:

• I can't get in — login clusters, 1,141 apps (17.2%), 4,909 reviews. Account recovery, social sign-in and OTP delivery are the usual suspects.
• It won't run on my device — device compatibility, 1,885 apps (28.4%). The most likely meaning of the five.
• It closes or hangs — crash (686 apps) plus freezing (387 apps). Two clusters, one user experience.
• It won't send my stuff — upload clusters, 294 apps (4.4%), 859 reviews. Small in the catalog, brutal for anything with user-generated content.
• It can't find me — location or GPS clusters, 480 apps (7.2%), 1,815 reviews. Concentrated in delivery, fitness and navigation apps.

Support silence is a complaint multiplier

Customer support is its own cluster in sixth place: 1,009 apps (15.2%), 3,379 reviews. Those are people complaining specifically that nobody answered them.

The matching number from the same catalog: 47.4% of audited apps (3,143) have never replied to a single review. The average reply rate across everything we've audited is 28.0%.

This is the cheapest fixable row in the table and I'll defend that strongly. A reply costs nothing, it's public, and it's the only part of a complaint you still control after it's been written. The next user reads the reply, not just the review.

The workload argument doesn't hold either. The average audited app collects 40.4 reviews a month — about ten a week, and only a fraction of those are negative. That is not an unmanageable inbox; it's twenty minutes on a Friday.

A good star rating does not mean you have no complaints

The rating spread across the audited catalog: 2,064 apps at 4.5 or above, 1,993 between 4.0 and 4.4, 1,315 between 3.0 and 3.9, and 402 below 3.0.

Now put that next to the headline: 4,131 apps (62.3%) have at least one complaint cluster, while only 402 apps sit below 3.0. The arithmetic forces the conclusion — the great majority of complaint clusters live inside apps that look healthy on the store page.

That's what a cumulative average does. An app with 40,000 lifetime five-star ratings and a live payment cluster still displays 4.6, because the rating is a lagging metric diluted by every happy user you ever had. It cannot show you a problem that started in March.

Read the 1-to-3-star band as a separate stream with its own trend line. That's the whole trick, and it's why the clusters in this study are built from that band only.

How to run this analysis on your own app

You don't need our catalog to do this. The method is deliberately simple enough to run by hand in an afternoon:

• Pull your most recent 200 reviews rated 1 to 3 stars. Recent matters more than complete.
• Tag each one against the twenty categories in the table above — that is the complete set the classifier uses, not a top slice. Resist inventing new categories on the first pass; you'll create a category of one.
• Any category with two or more matching reviews is a cluster. That's the same bar we use.
• Rank your clusters by matching review count, not by how annoying each one feels to you.
• Fix the top cluster, then reply publicly to every review inside it. The reply is half the work.

What this study cannot tell you

Installs, retention, conversion rate and revenue are not in here. They live in the developer console, they are not scrapeable, and we don't estimate them.

The catalog is not a random sample of the two stores. Apps enter it through keyword search, similar-app rails, developer portfolios and top charts, and the crawl deliberately excludes Games. Read the ranking as what complaints look like across a broad slice of non-game consumer apps, not as a census of the App Store.

Nothing here is causal. We can say that 28.6% of audited apps have a payment cluster. We cannot say a cluster caused a rating to fall, because we don't hold the counterfactual.

And it's a snapshot of the audited catalog taken on 3 August 2026. The catalog grows continuously, so the live totals are higher than these, and clusters appear and disappear as reviews do. If you want the current state of a specific listing rather than the aggregate, that's what /app-audit and the catalog at /app-reports are for.