Ratings and reviews: how they affect ASO and what to do
Your star rating is one of the few public signals Apple lets users see before they tap Get, and it pulls double duty: it feeds the search algorithm and it gates conversion on your product page. The catch is that the three components (how many ratings you have, the average, and how recent they are) behave differently, and the legitimate tools you have to influence them (the in-app prompt, review responses) are deliberately rate-limited. The mistake most teams make is treating the rating as a single vanity number to push upward with one-off campaigns. It is better understood as a maintained system: a stock of ratings that ages, a current-version score that resets in importance every release, and a stream of recent reviews that both real users and the algorithm read first. You influence it through product quality and timing, not volume of asks. Every lever Apple gives you (SKStoreReviewController, App Store Connect review responses, the cadence of your releases) is bounded, so the discipline is spending limited prompts on genuinely satisfied users and responding fast to the reviews that hurt your visible signal most. Treat ratings as a system to maintain, not a number to chase.
How do ratings affect ranking versus conversion?
These are two separate effects, often conflated, and untangling them changes what you do about a rating problem. Ranking: Apple's algorithm uses rating average and volume as a quality signal, so a higher, well-populated rating helps you place better for the same text relevance. Two apps equally relevant to 'budget tracker' will not rank identically if one sits at 4.7 from 50,000 ratings and the other at 3.8 from 200. Conversion: the rating is shown in search results and atop your product page, so it directly changes how many people who see you actually download. A drop from 4.6 to 3.9 stars can cut tap-through meaningfully even when your rank is unchanged, because users scan the star figure before reading a word of your subtitle. Conversion then feeds back into ranking via download velocity: fewer taps means fewer installs from the same impressions, which the algorithm reads as weaker demand. So a rating problem hurts you three ways: as a direct ranking signal, as a conversion deterrent on the page, and again through the downloads that lost conversion costs you. This compounding is why a half-star slide can feel disproportionate to its cause.
Count, average, and recency are three different signals
Volume gives your average credibility and stability. A 5.0 from 8 ratings carries less weight, and swings far more violently, than a 4.5 from 8,000: a single 1-star review moves the former by a full point and the latter by nothing. Average is the headline conversion number users scan and the figure Apple renders in search results. Recency matters because Apple weights the current version's ratings prominently and surfaces recent reviews first; a great lifetime average can hide a collapsing current-version score after a bad update. Track all three independently. A common trap is a healthy all-time average masking a current-version rating that cratered post-release: users see the recent one-star reviews at the top of the page, and the algorithm sees the recent signal, long before your lifetime average moves enough to notice. Equally, a brand-new app with a 4.9 from 30 ratings is fragile: it has no buffer, so its first wave of real-world users can drag it down fast. Watch the trajectory of the current-version score after every release, not just the lifetime number on your dashboard, and pull the country-level RSS feed so you can see which storefront a slide is coming from.
How should I use the in-app rating prompt?
Use SKStoreReviewController (or requestReview on the AppStore scene in newer SDKs). It shows Apple's native sheet, lets the user rate without leaving your app, and, critically, Apple caps it at 3 prompts per app per 365-day window per device. So spend those prompts wisely. Trigger after a clear success moment: a completed workout, a saved project, a finished export, a won game, a third consecutive day of use. Never on launch, never mid-task, never inside a paywall, and never after an error or a crash recovery: a user who just hit a bug is the worst possible person to ask. Do not gate the prompt behind a 'did you like it?' upsell or bribe for stars; both violate App Store Review Guideline 5.6 and risk rejection. On iOS you cannot force the dialog to appear; the system may suppress it (for instance if it has already shown recently on that device, even from a prior install), so design the flow assuming it might not show and never block functionality on it. Because the cap is per device and per year, instrument your own counter so you don't waste prompts firing them too close together or all at once on power users who would have rated you anyway.
Does responding to reviews help, and how?
Yes, and it is one of the few free levers fully in your control. Replying via App Store Connect notifies the reviewer, and a meaningfully resolved complaint often gets edited upward to a higher star rating, which moves both your average and your current-version score, the two figures that matter most. Beyond the individual review, public replies show prospective users browsing your page that you are responsive and that complaints get answered, which lifts conversion independently of any rating change. Prioritize recent, low-star, current-version reviews: they sit at the top of your page and hurt the visible signal most. Be specific rather than templated: name the bug, point to the version that fixes it, or give a concrete workaround. A reply that reads 'Thanks for your feedback!' converts no one and edits no rating; one that says 'This crash on iPad is fixed in 4.2, out today; please update and let us know' frequently flips a 1-star to a 4. There is no Apple-imposed cap on responses, so this is your highest-leverage, lowest-risk ratings activity. Pull the review RSS feed per country (Apple caps it at roughly 500 reviews per app per storefront) to triage at scale rather than refreshing the dashboard by hand.
How do I recover from a rating drop after a bad release?
Recovery is mechanical, not magical. First, fix the underlying bug and ship the patch fast; recent ratings are weighted, so the sooner good current-version ratings start flowing, the sooner the visible score recovers; a week's delay is a week of one-star reviews accumulating at the top of your page. Second, respond to the angry recent reviews pointing to the patch version; many reviewers will revise upward once notified, and those edits land on the current-version score where they help most. Third, resume your in-app prompt only after the fix is live and you are confident the success moment genuinely succeeds, so your remaining yearly prompts capture satisfied users rather than fresh victims of the bug. Do not reset ratings; you cannot, short of shipping a new SKU, which throws away all your history and is almost never worth it. Do not solicit fake positives or run a burst of incentivized five-stars to dilute the average; Apple detects coordinated rating manipulation and the pattern is obvious in the data. The path back is: stop the bleeding with a fast patch, earn fresh recent ratings from real satisfied users, respond to the loudest recent complaints, and let the recency weighting do the rest over the following weeks.
What counts as legitimate versus a Guideline 5.6 violation
The line Apple draws is about manipulation and coercion, not about asking. You may show the native prompt after a success moment, reply to every review, and link to your support channel; all sanctioned. You may not do anything that filters who gets to rate or pays for the outcome. Banned patterns include: gating the prompt behind a 'Do you love the app?' fork that routes happy users to the App Store and unhappy ones to a private feedback form (review filtering), offering coins, unlocks, or discounts in exchange for a rating, building your own star-picker UI that posts to the App Store, or nagging repeatedly with custom dialogs to route around Apple's 3-prompt cap. Incentivized and review-filtered ratings are the two most common reasons ASO-driven apps get rejected or have ratings reset. The safe rule: use Apple's native sheet, ask everyone unconditionally at a good moment, and never let the reward or the routing depend on how the user feels. Buying reviews from third-party services is both a guideline violation and detectable; the short-term average bump is not worth a reset or removal.
Reading reviews as a product and keyword signal
Reviews are not only a rating input: they are free, structured feedback and a keyword research source most teams ignore. Cluster your recent reviews by theme to find the bugs and missing features driving low scores; the same complaint appearing across twenty reviews is a roadmap item that will lift your rating faster than any prompt tuning. Reviews also reveal the language real users use to describe your app, which is gold for the 30 characters of your subtitle and your 100-byte keyword field: if reviewers consistently call your app a 'sleep tracker' while your metadata says 'rest monitor,' your metadata is missing the term people actually search. Watch for sudden shifts in review sentiment after a release as an early warning that lands before the aggregate score moves. Pull reviews per storefront via the public RSS feed so you can localize both your fixes and your responses; a crash that only shows up in the German reviews points at a locale-specific bug. Quantify the patterns rather than reacting to the loudest single review; one furious outlier is noise, but a consistent cluster across the current version is signal worth shipping against.
Tracking ratings across versions and storefronts
Ratings are not one number: they are a matrix of lifetime versus current-version, per storefront, over time, and the aggregate dashboard figure hides most of what you need. Apple resets the prominence of the rating with each version in the sense that current-version ratings are weighted and surfaced, so a quiet release can carry a hidden score even while the lifetime average looks flat. Track the current-version average separately and chart it from the moment a release goes live, because the first 48 hours after a rollout are where a regression shows up first. Do the same per country: a global 4.6 can conceal a 3.2 in a single large market caused by a localization bug or a payment failure specific to that storefront, and that local slide quietly costs you rank in that storefront alone. The sanctioned way to gather this is the per-country review RSS feed plus your own App Store Connect data; never scrape the store. Set a threshold alert on the current-version score so a post-release drop pages you within hours, not whenever you next glance at the dashboard. The teams that recover fastest from rating slides are the ones that detect them in the version-and-storefront breakdown before the lifetime average ever moves.
FAQ
How many times can the in-app rating prompt appear per year?
Apple caps SKStoreReviewController at a maximum of 3 prompts per app per device within a rolling 365-day period. The system may also suppress it entirely (for example if it has shown recently on that device) so you cannot guarantee it appears. Design your flow so nothing breaks if the sheet never shows, and instrument your own counter so you don't waste prompts by firing them too close together on the same user.
Can I ask users to rate the app and screen out unhappy ones first?
No. Gating the rating prompt behind a 'do you like the app?' question to route happy users to the store and unhappy ones to a feedback form, or incentivizing ratings with rewards, violates App Store Review Guideline 5.6 and can get your app rejected or its ratings reset. This review filtering is one of the most common causes of ASO-driven rejections. Use the native prompt unconditionally after a genuine success moment, and offer support to everyone equally.
Does replying to a review change my rating?
Indirectly, and it is your highest-leverage free lever. Your reply via App Store Connect notifies the reviewer, who can edit their rating upward after you resolve their issue, moving both your average and, more importantly, your current-version score. There is no limit on how many reviews you can respond to. Prioritize recent, low-star, current-version reviews, name the specific fix or workaround, and avoid templated replies, which rarely move anyone.
Why did my rating drop after an update when my lifetime average is fine?
Apple weights the current version's ratings and surfaces recent reviews first. A bad release tanks the current-version score and the recent reviews users see at the top of your page, even while your all-time average still looks healthy because it is diluted across years of history. Track the current-version rating separately, and chart it from the moment each release goes live so a regression pages you within hours rather than whenever the lifetime number finally moves.
Should I track ratings per country?
Yes. A global average can hide a serious slide in a single large storefront caused by a localization bug, a payment failure, or a region-specific crash, and that local drop costs you rank in that storefront alone. Pull the per-country review RSS feed (capped around 500 reviews per app per storefront) plus your own App Store Connect data to break the figure down by version and market. Never scrape the store; the RSS feed and ASC are the sanctioned sources.
Can I delete or reset bad reviews?
No. You cannot delete individual reviews or reset your rating short of shipping an entirely new SKU, which discards all your history and rankings and is almost never worth it. The legitimate path is to fix the underlying issue, ship the patch fast so weighted current-version ratings recover, respond to the angry recent reviews pointing at the fix so reviewers revise upward, and resume prompting satisfied users once the success moment genuinely succeeds again.
appusula puts these checks in one self-hosted dashboard: keyword ranks, metadata validation, competitor tracking, and AI visibility.
Get started