Get in touch
Gabs
Blog

Bad app reviews blame price before bugs once you charge

Yes, if you charge: in 10 of 11 paid apps, 1-2 star reviews mention price more than bugs. The 12.7% App Store average hides it.

Gabriel EspinheiraSenior Full-Stack Engineer
  • Published
  • 9 minReading time
  • ProductCategory

Listen to this post· AI-narrated

0:00 / 9:15

A one-star review that says "just wants money" gives you nothing to fix, and an indie developer on r/iosdev (opens in a new tab) asked whether Apple should filter those out. Then on 6 November 2026, Obelisk Club (opens in a new tab) published numbers on bad app reviews: 12.7% complain about subscription and price, 10.9% about bugs. Nearly a tie. I didn't trust the tie, because nobody can complain about the paywall of an app that doesn't have one. So I pulled the latest reviews for 14 apps and split them by whether the app charges. In the apps with a paid tier, bad reviews mentioned price about two and a half times as often as bugs. So I wouldn't start with the price.

TL;DR: If your app charges, bad reviews mention price far more than bugs: 40.3% against 16.4% across 11 paid apps I checked, and 10 of the 11 leaned that way. Only about a quarter of those reviews use words about the amount. Fix billing surprises and locked purchases before you touch the price.

Do bad app reviews complain more about price or bugs?

Across the App Store, price is the top complaint in bad app reviews, but only just. Obelisk Club (opens in a new tab), a research site that tracks the App Store charts, read 165,735 recent US reviews of 3,912 apps and tagged the 1 and 2 star ones by keyword. Subscription and price came first at 12.7%, then bugs and broken features at 10.9%, then login and account at 10%. One review can count under several themes.

That average blends apps that can't draw a price complaint with apps that draw them daily. The same report found that 26.7% of free-to-download apps in the charts say they sell in-app purchases or subscriptions, and it calls that share low, since apps that say nothing may still sell something. It publishes no split of complaints by how an app makes money. You need that split to decide anything about your own paywall.

What happens to bad reviews once an app charges?

Once an app has a paid tier, price becomes the main complaint. On 6 November I pulled the 500 most recent US reviews for each app from Apple's public feed, kept the 1 and 2 star ones and tagged them with my own keyword lists.

AppBad reviewsMention priceMention bugs
Halide25864%12%
Calm16254%23%
CARROT Weather13646%7%
Goodnotes26545%22%
Day One11141%19%
Strava20438%23%
Tinder40734%10%
Bear10928%20%
Flighty8028%8%
Duolingo8227%6%
Overcast14614%32%
Google Maps2795%13%
Gmail3993%13%
WhatsApp1982%11%

Pool the 11 apps with a paid tier and you get 1,960 bad reviews, 40.3% mentioning price and 16.4% mentioning bugs. Pool the three whose main job isn't behind a paywall and you get 876 bad reviews, 3.6% against 12.2%, and neither group looks like the 12.7% average. Smaller apps lean the same way as the big names: CARROT Weather, Flighty and Bear all draw more price complaints than bug reports.

Overcast is the exception, with 32% mentioning bugs, and about half of its price reviews mention bugs too. Other apps get both complaints in one review less often. Across the paid apps, 14.4% of the price reviews also use bug words, like the Calm reviewer "paying a hefty price for an app that is full of bugs." Drop those and price still reaches 34.4%, twice the bug rate.

I chose these apps by hand, so read this as a strong pattern in apps developers know, and don't quote it as a rate for the store. The feed only covers recent reviews, so one pricing change can swing an app. Halide's 64% could be that, and I didn't date it. The count also shows only what people write. It doesn't show a price complaint cost anyone a star, and I haven't found data that does.

Are price complaints about the price?

Mostly they aren't about the amount, which is why the argument in the r/iosdev thread goes nowhere. The developer wrote that "a pricing opinion isn't a product review." A reply answered that "a pricing opinion is a product review." I side with the reply, because how you bill is part of the product. A trial that renews without warning is a design decision, and a purchase that vanishes after a renewal is a bug.

A cheaper plan doesn't help the Strava reviewer whose whole complaint is "Impossible to cancel subscription." I split the 789 price reviews from the paid apps again, and only the first of these groups is asking for a lower price. A review can land in several, and 27.8% matched none of them:

  • The amount: 24.2% use words like expensive, too much or a month.
  • Billing: 22.9% mention a refund, a cancellation, a trial or being charged.
  • The wall: 26.4% are about what's locked, with words like paywall, premium or used to be free.
  • Already paid: 25.6% come from people who say they paid, often for something that stopped working. One Calm reviewer bought a lifetime membership in 2019 and says it disappeared.

What should you fix before you cut your price?

Some of it you should ignore. A review that says only "just wants money" may come from someone who was never going to pay, and no price short of free answers them.

For the rest, fix what makes people feel tricked first, since none of it means charging less. This order is my judgement from reading these reviews, and I haven't measured it.

  1. Billing surprises. Apple runs cancellation for in-app subscriptions, but you can put a button in your settings that opens its screen with AppStore.showManageSubscriptions. Say what happens when the trial ends, too. Apple's guideline 3.1.2(c) (opens in a new tab) already asks you to "clearly describe what the user will get for the price." Clearer terms may cost you some trial starts, and I'd take that trade.
  2. Paid but locked out. Test restore, renewal and lifetime purchases on a real device, on every release. Write them as automated tests where you can. These reviewers have already given you money.
  3. The wall. Look at where a free user first hits it. If they can't tell what the app does before you ask for money, that's the review you'll keep getting.
  4. The amount, last. Cut the price only if the amount group clearly outnumbers the others in your own reviews and the people writing them clearly used the app. A cut reaches every paying customer, and the other three groups will still have their complaint.

Can you remove bad reviews that only complain about price?

Mostly you can't, and the workaround people suggest breaks Apple's rules. In the r/iosdev thread, one developer said reporting these as off topic "works in many cases," while the original poster kept getting a reply that the review doesn't break any policy.

Another commenter suggested a "loving the app?" popup that sends only happy users to the App Store. Apple's guidelines (opens in a new tab) say "we will disallow custom review prompts," and they name "filtered" feedback among the ways of manipulating reviews that can get you expelled from the developer program. Use Apple's requestReview, at a moment when the app just did something useful.

Reply to the billing and already-paid reviews instead, since those people have a problem you can solve. As a developer on r/googleplayconsole (opens in a new tab) put it, "The reply is mostly for the next person who opens your listing, not for the reviewer."

How do you count your own app's bad reviews?

Apple's customer reviews feed needs no key, so a short script gives you your own version of the table above in a minute. Save this as count-reviews.mjs and run node count-reviews.mjs <app id>, using the number in your App Store URL.

const PRICE = /subscri|paywall|price|pricing|expensive|overpriced|\bpay\b|paying|\bpaid\b|money|charg|\bcost|refund|premium|\btrial\b/i
const BUGS = /\bbugs?\b|buggy|broken|glitch|doesn.?t work|not working|won.?t work|stopped working|\berrors?\b|\bfix\b/i
const KINDS = {
  amount: /expensive|overpriced|too much|\bprice|pricing|\b(a|per) (month|year)\b|\bcosts?\b/i,
  billing: /refund|cancel|auto.?renew|charged|\btrial\b|unsubscribe/i,
  wall: /paywall|premium|\bpay to\b|have to pay|need to pay|behind|locked|used to be free|was free|not free/i,
  alreadyPaid: /lifetime|already (paid|purchased|bought|subscribed)|restore|i paid|i pay\b|paid for|paying for|i bought|purchased/i,
}
const low = []
for (let page = 1; page <= 10; page++) {
  const url = `https://itunes.apple.com/us/rss/customerreviews/page=${page}/id=${process.argv[2]}/sortby=mostrecent/json`
  const { feed } = await (await fetch(url)).json()
  if (!feed?.entry) break
  for (const review of [feed.entry].flat())
    if (Number(review["im:rating"]?.label) <= 2) low.push(`${review.title?.label} ${review.content?.label}`)
}
const share = (list, words) => `${Math.round((100 * list.filter((text) => words.test(text)).length) / list.length)}%`
const priced = low.filter((text) => PRICE.test(text))
console.log(`${low.length} bad reviews: price ${share(low, PRICE)}, bugs ${share(low, BUGS)}`)
for (const [kind, words] of Object.entries(KINDS)) console.log(`  ${kind}: ${share(priced, words)} of price reviews`)

The feed stopped at 500 reviews for every app I tried, one store at a time, so change /us/ for other markets.

The one gotcha is that keywords don't know your domain. I also ran Chase's banking app as a check, and 22% of its bad reviews tagged as price, because a bank's customers write "pay" and "money" about their accounts. In ordinary free apps the same list only picks up 2% to 5%, and when I read a random 42 of the tagged reviews from the paid apps, most were about paying, with a handful mentioning money in passing. Read 20 of yours before you believe the number, and fix the word list until it matches your app.

What to do this week

Run the script on your app. If you don't charge, your bad reviews are mostly about the product, so keep fixing it. If you do charge, sort your price reviews into the four groups, then check cancelling and restore on a real device today. Touch the price only when the amount group clearly outnumbers the rest.

More posts on building software are on the gabs.app blog. I'm a full-stack engineer and my work is on gabs.app; if you're hiring, the contact form comes straight to me.