App Store Reviews: Get More Ratings and Respond the Right Way

In short: Ask for ratings with the system prompt only (RequestReviewAction or AppStore.requestReview on iOS, the In-App Review API on Android), right after a user succeeds at something, never on first launch and never from a button. Apple shows the prompt at most three times a year, Google applies an undisclosed quota, and both stores ban incentives and pre-prompt questions. Reply to low-star and bug reviews first, keep replies short and specific, and tell people when a fix ships: both stores notify the reviewer, who can then update their rating.

Ratings decide whether a stranger trusts your store page, and Google says plainly that Play ranks apps on "a combination of ratings, reviews, downloads, and other factors". Most teams know they need more reviews. Fewer know exactly where the rules sit, so they either under-ask or build a prompt flow that a reviewer at Apple or Google would reject.

This guide covers the current rules on both stores (verified against Apple and Google documentation as of October 2026), when to ask, how to reply, and how to turn reviews into a roadmap.

The rules, as of October 2026

App Store

The API. Apple now marks SKStoreReviewController as deprecated (since iOS 18). Use RequestReviewAction in SwiftUI (read the requestReview environment value and call it) or AppStore.requestReview(in:) with a UIWindowScene in UIKit. Both are available from iOS 16. If you still support older iOS versions, keep the old call behind an availability check.

The limit. For someone who has not rated your app on that device, StoreKit shows the prompt a maximum of three times within a 365-day period. If they already rated or reviewed it, the prompt only appears for a new app version and after more than 365 days since their last review. People can also turn these prompts off for every app.

The call may do nothing. Because the API may not present an alert, Apple says not to call it in response to a button tap or other user action. In development mode the prompt always appears; in TestFlight builds the call has no effect, so do not judge your flow from a beta.

A permanent link is fine. Apple's documentation suggests a persistent link to your product page in settings, with action=write-review appended to the URL so it opens the write-a-review sheet. That is the right home for a "Rate Streakly" row.

What App Review enforces. Guideline 5.6.1 says to use the provided API and that Apple "will disallow custom review prompts." Guideline 3.2.2(x) says apps must not force users to rate or review the app to access functionality or content. Guideline 5.6.3 (Discovery Fraud) forbids manipulating reviews, and the Section 3 introduction warns that paid, incentivized, filtered or fake feedback can get you expelled from the Apple Developer Program. "Filtered" is the important word: a flow that sends happy users to the store and unhappy users to an email form is exactly that.

Google Play

The API. The Play In-App Review API shows a review card inside your app. Google enforces a time-bound quota per user. The exact value is an implementation detail that can change without notice, so calling launchReviewFlow more than once in a short period (Google's example: less than a month) may show nothing.

The design rules. Show the card as-is: no resizing, no overlays, no removing it programmatically. Do not put a "Rate us" button in front of the API either, because a user who has hit their quota gets a broken experience. Send button taps to the Play Store instead.

No questions first. Google is explicit: your app "shouldn't ask the user any questions before or while presenting the rating button or card," including opinion questions such as "Do you like the app?" and predictive ones such as "Would you rate this app 5 stars".

No incentives. The User Ratings, Reviews, and Installs policy prohibits manipulating ratings, reviews or installs. Listed violations include offering a discount or other incentive for a rating, and encouraging reviews that contain links, coupons or codes.

Side by side

When to ask: success moments, not launches

Apple's Human Interface Guidelines say to ask only after people have shown engagement, never on first launch or during onboarding, never in the middle of a task, and to allow "at least a week or two between requests." Google says to ask once a user "has experienced enough of your app or game to provide useful feedback." Turn that into code with a gate, not a timer.

A worked gate for a hypothetical app

Take Streakly, a hypothetical habit tracker. Its prompt fires only when all of these are true:

1. The user just completed a 7-day streak and is on the celebration screen for at least two seconds.
2. They have opened the app on at least 5 different days.
3. No crash or failed sync happened in this session.
4. The app has not requested a review for this app version.
5. At least 14 days have passed since the last request.

None of these conditions asks the user anything, so it stays inside both stores' rules. Apple's own sample project uses the same idea: it waits for a process to be completed several times, never prompts twice for the same bundle version, and waits a few seconds on the completion screen.

@Environment(\.requestReview) private var requestReview

func streakCompleted() {
    guard ReviewGate.shouldAsk(version: appVersion) else { return }
    ReviewGate.markAsked(version: appVersion)
    requestReview()
}

For feedback from unhappy users, give everyone the same permanent "Send feedback" row in settings or help. It must not decide who sees the system prompt.

The rating math: how many 5-star ratings you need

If your current average is A from N ratings and new ratings average R, the number of new ratings x you need to reach a target T is:

x = N × (T − A) / (R − T)

Lifting a 3.9 to a 4.3, assuming a simple average:

Check for 1,000: (1,000 × 3.9 + 572 × 5) ÷ 1,572 = 4.30. Two lessons follow. Realistic new ratings are never all 5 stars, so the real number is closer to the middle column. And the gap between R and T matters more than volume: fixing what produces 1-star reviews moves R, which shrinks x faster than any prompt tweak.

Two store-specific caveats. Google says the rating users see on Play is weighted towards more recent ratings, so a better version recovers faster than this table suggests. Apple's summary rating is per territory, so do this math per country, starting with the countries that bring most of your downloads.

Resetting the App Store summary rating

Apple lets you reset the summary rating when a new version is released (Admin or App Manager role): on the version page, select "Reset rating when this version is released" and save before you submit. What to know first:

• It applies to all countries at once when the version goes live.
• It cannot be undone after release.
• Written reviews stay on the page.
• The product page says the rating was recently reset until enough people rate the new version.

Apple recommends using it sparingly. Our rule of thumb: reset only when the low rating is driven by a problem the new version fixes, and when your prompt gate can rebuild a meaningful count within a few weeks.

How to respond to reviews

What each store gives you

On the App Store, users with the Account Holder, Admin or Customer Support role can reply in App Store Connect under Ratings and Reviews. Only one response per review is shown, it can take up to 24 hours to appear, and you can edit or delete it later (edited responses are marked). Apple's ratings and reviews page adds that the reviewer is notified when you respond and has the option to update their review, that you can respond to reviews of any age, and that you can get email alerts when a user edits a review you replied to.

On Google Play, anyone with the "Reply to reviews" permission can post one public reply per review and edit it at any time. The user receives a push notification and an email, and can update their rating or review. If you reply through the Reply to Reviews API, the reply is limited to 350 characters of plain text, the API only returns reviews created or modified in the last week, and only the first reply to a review triggers a notification.

Both stores ask for the same tone: concise, respectful, specific, with no personal information, marketing or spam. Google adds that replies should focus on the user's issue and not ask for a higher rating.

Who to answer first

Apple's own advice: if you cannot reply to everything, prioritize the lowest ratings and reviews that mention technical issues with the current version. We would add a target, as a recommendation rather than a store rule: reply to 1–2 star reviews within one business day while the user still has the app installed, and to everything else within a week.

Reply templates

Each template below fits in 350 characters, so it works on both stores. Personalize the bracketed parts; Apple explicitly recommends personal replies over generic ones for similar reviews.

1 star, bug report

Thanks for flagging this, [name]. You're right: [feature] fails on [device/OS] after the last update. We found the cause and the fix is in version [x.y], out this week. If it still happens after updating, email support@[app].com with your device model and we'll look at it directly.

1 star, missing feature

Fair point, [name]. Streakly can't [do X] yet. It's the most requested feature this month and it's on our roadmap, but we won't promise a date we can't keep. Until then, [workaround, if one exists]. We'll reply here when it ships.

2 stars, price complaint

Thanks for the honest feedback. The free plan includes [core features]; Premium adds [specific features] and costs [price/period]. You can cancel anytime from your account settings. If something you expected to be free isn't, tell us which part at support@[app].com.

5 stars, thank you

Thank you, [name]! A [N]-day streak is no small thing. If there's one thing that would make Streakly even more useful for you, tell us here; we read every reply.

Review meant for another app, or about the store

Thanks for writing. It sounds like this may be about a different app, since Streakly doesn't [feature mentioned]. If it is about us, email support@[app].com with what you saw and we'll sort it out. For billing issues, [Apple Support / Google Play Help] can help directly.

What to leave out: discounts, codes or "update your rating and we'll…" offers (incentives), promises with dates you are not sure of, arguing with the reviewer, and anything that identifies the user. For billing and download problems on iOS, Apple asks you to point the user to Apple Support.

Closing the loop after a fix

When a release fixes something reviewers complained about, Apple recommends saying so in the release notes and replying to the relevant reviews. Because the reviewer is notified and can update their review, this is the most honest way to win back stars. On Google Play, editing an existing reply does not send a new notification, so announce fixes in the release notes as well.

When not to reply: report it

If a review contains offensive material, spam or content that breaks the store terms, use Report a Concern in App Store Connect instead of replying (the user is not told). On Google Play, report it from the review in Play Console. Do not answer abuse in public.

Turn reviews into a roadmap

Replies fix one relationship. The bigger win is reading reviews in aggregate.

1. Tag every review with one primary topic from a short, stable list: bug, performance, pricing, missing feature, UX confusion, sync/data, praise. Keep the list under ten tags or nobody will use it consistently.
2. Count weekly, by version and country. A topic that jumps after a release is a regression. A topic that grows slowly is a roadmap item.
3. Rank by damage, not volume. Weight 1-star mentions more than 3-star ones. Ten 1-star "sync lost my data" reviews outrank forty 3-star "would love dark mode" ones.
4. Quote, don't paraphrase. Put two or three real review quotes in each ticket. Engineers fix what they can picture.
5. Read your competitors' 1-star reviews. The complaint themes that repeat across rival apps are the gaps a better product can fill.
6. Close the loop with release notes and replies, then watch whether that topic's share drops.

Apple now also shows LLM-generated review summaries on product pages in the United States and eight more English-language storefronts. Whatever your reviewers repeat most is what a shopper will read first, which is one more reason to fix recurring complaints rather than just answer them.

Common mistakes

• A "Rate us" button wired to the review API. It shows nothing once the quota is used. Link to the store page instead.
• "Enjoying Streakly? Yes / No" before the prompt. Forbidden on Google Play, treated as a custom review prompt on iOS.
• Prompting on launch after an update. Apple advises against asking immediately when the app launches, even if it isn't the first launch.
• Asking only users who just contacted support happily. That is filtering, which Apple names as manipulation.
• Copy-paste replies. Identical text under fifty reviews reads as a bot and helps nobody.
• Resetting the rating to hide a bad week. It wipes your count everywhere and does not remove the written reviews.
• Ignoring country. A 4.6 in the US can hide a 3.8 in Germany after a translation bug.

How Searvia helps

Searvia's review tools group your latest reviews into topics with a next step for each, draft replies in the reviewer's language that you edit and approve, and publish them through the official API once App Store Connect or Google Play is connected (optional review agents can draft, tag and flag reviews automatically, and only publish without approval if you turn that on). Rating tracking follows your rating by country and alerts you the morning a country drops by 0.1 or more within 7 days, and complaint maps turn any app's 1–2 star reviews into themes with real quotes. See how it fits together in app review analysis.