Tolaron
Write to us

Tolaron RadarBefore you start

What a 3.8-star rating says about your app, and what it doesn't

An app store rating mixes old versions, one Android model and backend outages. How to read reviews by version and OS, and when a fix beats a rewrite.

Zdeněk Dolák · Founder8 min read
A phone in a navy case face down on pale blue paper beside a row of five small wooden stars, four navy and one coral, and a folded paper strip
On this page

A 3.8-star rating tells you that enough people were unhappy to say so. It does not tell you why, which version they were on, which phone they held, or whether the app or the system behind it was at fault. The number on the product page is an average over time, versions, devices and countries, so two apps with the same rating can need completely different work: one a week of fixes, the other a new app.

Before you decide anything, split the number. Both stores let you break reviews down by app version, and Google Play also by Android version, device model and country. Read the complaints by cluster rather than one by one, and sort them into the three places a complaint can come from: the app itself, the backend and services it depends on, and the business behind it. Only then does the question "fix or rewrite" have an answer.

This article explains what the rating is made of in each store, the patterns that make it misleading, how to read reviews so they point to a cause, what the two stores let you do about the rating itself, and how to tell a fix from a rewrite. The examples are fictional.

What the number is made of

The two stores calculate and show the rating differently, and that matters before you compare your iOS and Android numbers.

App Store. Apple shows one overview rating for the app. When you release a new version, App Store Connect gives you the option to reset it. The reset applies to the rating only; written reviews stay on the product page. It applies in all countries at once, and it cannot be undone once the version is out. A reset is therefore a decision, not a routine step, and we come back to it below.

Google Play. The rating users see is weighted towards recent ratings, and Play Console shows the lifetime average separately. Ratings do not start over when you publish a new version. Play Console breaks the rating down by country, language, app version, Android version, device type, device model and operator.

Google Play holds a new review back for around 24 hours before it appears, and both stores show reviews by version. That one filter is the most useful thing in either console, because a complaint about a version nobody has installed for a year is history, not a defect.

Four patterns that make the number lie

Fictional examples, from the kinds of apps we are asked about.

The old version. A field-service app shipped a bad release eighteen months ago, fixed it in a week, and has been stable since. On Google Play, the weighting towards recent ratings has let the public number recover. On the App Store, every one-star review from that month still counts in the overview rating unless it has been reset. The same app, two numbers.

The one phone. A retail loyalty app rates well everywhere except on one Android device model, where it crashes at the barcode scanner. The owners read "crashes all the time" in the reviews and plan a rewrite. Play Console's breakdown by device model shows the problem in one row.

The bad week. A banking-style app's backend was down for two evenings. Every review from those days says "doesn't load" or "error after login". The app did nothing wrong, and no release will change those reviews. The backend owner's incident log explains them, and the fix is on their side, not in the app.

The badly timed prompt. An app asks for a rating the moment a payment fails, or in the middle of a form. People who were interrupted rate the interruption. Apple and Google both say when the prompt should appear, and we cover their rules below. An app with a rating problem often has a prompting problem first.

Reading reviews so they point to a cause

Read the last few hundred reviews across both stores, sorted by version, and put each complaint in one of three columns: app, backend and services, or business. The table below shows the usual sorting. It is a starting point, not a verdict; the same words can mean different things, which is why the check column exists.

Scroll sideways to see every column.

What people writeWhat it usually meansWho owns itHow to check
"Doesn't load", "spinning forever", "error after I log in"The API was slow or down, or the app handles a slow network badly. Often both.Backend owner first; the app for how it failsMatch review dates against the backend's incident and response-time logs.
"Crashes on my phone", "closes when I open the camera"A defect tied to a device model, an OS version or one feature.The appCrash data by device and OS version in Play Console and App Store Connect; the version filter on reviews.
"New version is worse", "it worked before the update"A regression in a release, or a change people did not want.The app, and whoever approved the changeCompare reviews of the two versions; look for the release notes of the version that turned.
"Had to log in again", "my data is gone"Session or migration handling in an update, or a change on the server side.App and backend togetherReproduce an update from the previous version on a real device with real data.
"Can't find X", "too many steps", "where is the button"Design: the task is possible but the path is unclear.The appWatch five users do the task; count taps against the main competitor.
"The code never arrives", "no notifications"A third-party SMS, e-mail or push provider, or its account and limits.The owner of that provider's accountThe provider's delivery logs; the account's quota and billing.
"Why does it want my location", "stop tracking me"Permission requests that come too early or without a reason shown.The app, with your privacy ownerWhere in the flow each permission is requested and what the user sees first.
"Rude staff", "too expensive", "delivery was late"Not the app. People review the company where they can.The businessRoute these to customer service; they still count in the number.

Two things follow from the sorting. First, the share of complaints the app itself owns is usually smaller than the rating suggests, and that share is what a development budget can change. Second, the backend and provider columns need their owners at the table before anything is decided, because releasing a new app on top of the same outages produces the same reviews. The article on what your API needs lists what to ask the backend owner.

The numbers behind the stars

Reviews are what people chose to write. The consoles also hold what happened to everyone, and the two should be read together.

Google publishes the thresholds it uses to judge an Android app's technical health. An app shows "bad behaviour" when at least 1.09 percent of daily users experience a crash the user noticed, or at least 0.47 percent experience an app that stopped responding, across all devices; or when either reaches 8 percent on a single device model. Google judges this over the last 28 days and says an app above the thresholds is likely to be less discoverable on Google Play. So a crash problem costs you twice: in reviews and in search.

On both platforms, ask your supplier for the crash-free rate of the current version and of the version most people actually run. If they cannot produce it, that is a finding in itself: the app has no monitoring, and the reviews are your only instrument.

What you can do about the rating itself

Reply. Both stores let you post one public reply per review and edit it later. On Google Play the reviewer gets a push notification and an e-mail, and can update their rating or review afterwards; on the App Store a reply can take up to 24 hours to appear. A reply works when it says what was fixed and in which version. It does not work as an apology sent to every one-star review on the same afternoon. The useful order is fix first, release, then reply to the reviews that reported that problem.

Ask at the right moment. Both platforms provide a system prompt for ratings, and both limit it. On iOS, the system shows the request at most three times in 365 days to a person who has not rated the app on that device, and once they have, only for a new version after more than a year. Google Play enforces a time-bound quota on how often one user sees the dialogue; the exact value is not published, and calling it more than once a month may show nothing. Google also says the app must not ask the user anything before the prompt, including "do you like the app?", and must not have a button that triggers it. Apple's guidance is to avoid interrupting a task. In practice: ask after a completed task, never after an error, and never only the people you think are happy.

Reset, on the App Store only. Apple lets you reset the overview rating when you release a new version. It is the right tool after a real rewrite that removes the reasons behind the old reviews, and the wrong one after a patch, because the written reviews stay visible and new one-star ratings on a small base pull the number down fast. There is no equivalent on Google Play, where the weighting towards recent ratings does the same job gradually.

Fix or rewrite

The review sorting usually answers this. Three signals point to a fix:

  • The complaints cluster. One version, one device model, one feature or one provider accounts for most of them. That is a list of defects, and defects are fixed one by one.
  • The app can be built and released by someone other than its original author. If nobody on your side has the code, the accounts and the signing keys, settle that first. The article on who owns your app is the checklist.
  • The backend owns a large share. Then the app is not the problem, and a new app will inherit it.

Three signals point to a rewrite:

  • Nobody can build it. The code depends on tools, libraries or a person no longer available, so each OS release is a risk. The posts on iOS 27 and the iPhone Duo show what a stale app faces every autumn.
  • The complaints are about what the app is, not how it works. People want a task the app was never designed for, or the app duplicates a website that serves them better. The article on an app or a better mobile website is the honest version of that question.
  • The fix list is the whole app. When every screen has a cluster of its own, the cost of fixing approaches the cost of building, without the benefit of a design that fits today's users.

If you ask us to look at an existing app, this sorting is what we do first, with the review export, the crash data and the backend owner in the room. What we build is described on the mobile app development page; the sorting itself needs no commitment from you.

What to do this week

  • Export the reviews from both consoles, filtered to the versions people actually run.
  • Sort them into app, backend and services, and business. Count each column.
  • Ask for the crash-free rate of the current version by device and OS, and check it against Google's thresholds.
  • Match "doesn't load" reviews against the backend owner's incident log.
  • Look at where the app asks for a rating, and move it to the end of a completed task if it is anywhere else.
  • Decide on fix or rewrite only after those five steps, and keep the App Store reset for a rewrite.

If you want a second pair of eyes on the sorted list, write to us.

Sources

All sources were checked on 21 October 2026.

Zdeněk DolákFounder of Tolaron. Spent the years before it building payment software.