App Store Rating & Review Management: Request Timing

App Store rating and review management is a trust-signal job more than a ranking one: firing StoreKit's requestReview() call at the right moment is the only reliable way to get a genuine review without annoying the user. This post walks through the official constraints in Apple's StoreKit documentation and Human Interface Guidelines (HIG), and Google's Play Core In-App Review API — what context the prompt requires, and what technical limits apply when replying to reviews. The goal isn't a made-up "best time" formula, but putting into practice what Apple and Google's own documentation actually says.

💡 Pro Tip: Tie the review request to a concrete achievement the user just completed, not a feature launch — StoreKit recommends showing it "after a series of events that they successfully complete," while Play Core requires that the user has gained enough experience to give useful feedback.

Table of Contents

• Where Rating Fits in Ranking and Conversion
• System Quotas: How Many Times a Year Can You Ask
• Spotting the Value Moment and Anchoring the Request to It
• Directing Users to Support: What the Official API Actually Says
• Which Events Count as a "Value Moment" in Practice
• Replying to Reviews: Scope and Technical Limits
• Tracking Rating Drops After a Release
• Forbidden Methods: Why Incentivizing and Filtering Are Risky
• FAQ
• When should the in-app review request be shown?
• How should bad reviews be replied to?
• How can the rating average be recovered?
• Why does the card sometimes never appear on Android?
• Can a user who dismissed the review request be asked again?
• Update (September 2026)
• Conclusion
• Sources

Where Rating Fits in Ranking and Conversion

Neither Apple nor Google has published a coefficient for how much rating affects App Store or Google Play search ranking. What we do have solid ground on is this: both platforms have reduced the review request from a custom interface the developer could design into a uniform prompt controlled entirely by the system.

On Android, Google explicitly forbids asking the user a separate opinion question ("Do you like the app?") before or while the card is shown, or overlaying your own design on top of it; the card must be shown as-is. This turns rating from a marketing metric the developer can fine-tune into a satisfaction signal that's closed to filtering. Its link to conversion is indirect: a high, current average rating acts as a trust cue that speeds up a user's download decision. Neither company publishes data measuring the size of that effect. The closest related piece, App Store Optimization (ASO), covers acquisition and ranking; this post focuses on rating/review operations after acquisition.

System Quotas: How Many Times a Year Can You Ask

StoreKit's documentation states the quota plainly: the system displays the review prompt to a user a maximum of three times within a 365-day period. Apple's sample project (the code in the StoreKit documentation) never even makes the call if the prompt has already been shown for the current bundle version: "a person doesn't receive a prompt to review the same version of an app multiple times." This isn't a guarantee the system enforces — it's a condition you must maintain in your own code. If the user chooses to, they can turn the prompt off entirely, and the system remembers that choice too.

On Android it's different: Google explicitly states that the quota value is an "implementation detail" and can change without notice from Play. So quoting a fixed "X times a year" number for Android would be wrong — your code must not assume the card will show every time launchReviewFlow() is called, and must not interrupt its flow if it doesn't.

1import StoreKit
2import UIKit
3 
4func userCompletedAValueMoment() {
5    // The user just completed a measurable achievement (e.g. 3rd project export).
6    // Do NOT call this during onboarding or mid-task.
7    Task { @MainActor in
8        if let scene = UIApplication.shared.connectedScenes
9            .first(where: { $0.activationState == .foregroundActive }) as? UIWindowScene {
10            AppStore.requestReview(in: scene)
11        }
12    }
13}

1val manager = ReviewManagerFactory.create(context)
2val request = manager.requestReviewFlow()
3request.addOnCompleteListener { task ->
4    if (task.isSuccessful) {
5        val reviewInfo = task.result
6        // The card may not show (Google's own quota decision) — design the UI flow accordingly.
7        manager.launchReviewFlow(activity, reviewInfo)
8    }
9}

Spotting the Value Moment and Anchoring the Request to It

StoreKit's documentation says to show the request "at the end of a sequence of events that they successfully complete" — not on first launch, and not as the direct side effect of a user action. The HIG makes this clearer: "Ask for a rating only after people have demonstrated engagement with your app or game" — meaning don't ask during onboarding, because the user "haven't had enough time to gain a clear understanding of your app's value." The same guideline adds that interrupting during a task or a game session "can disrupt the user experience and feel like a burden."

On Android, Google sums up the same principle in one sentence: "Trigger the in-app review flow after a user has experienced enough of your app or game to provide useful feedback." So the trigger isn't a screen count — it's whether the user has actually gained enough experience to give useful feedback.

In practice this means keeping an "achievement ledger" that counts concrete value events the user completed (an export, a sync, a completed order, a finished workout), not a blunt "session count reached N" counter. I covered the same timing logic for notification permission requests in Push Notification Permission Rate Optimization — "ask not on first launch, but the moment value is seen" applies here too. Both prompts are one-shot, system-quotaed, and the user can permanently dismiss either.

Directing Users to Support: What the Official API Actually Says

A common design pattern is: ask "Do you like the app?" first, route those who say "yes" to the store rating, and route those who say "no" to a support form. There's no confirming source for this flow in Apple's or Google's official documentation. On the contrary, Android's In-App Review guide explicitly forbids a version of it: you're not allowed to ask a separate opinion question, or a leading question, before or while the card is shown. The card must be presented as-is; you cannot add an extra layer or design change on top of it.

Which Events Count as a "Value Moment" in Practice

StoreKit's phrase "after a series of events that they successfully complete" stays abstract; it's more useful to give a few concrete examples by app type. In a productivity app, this might be the moment the user successfully exports their first project — the file downloaded, no error, the user saw the result. In a fitness app, the third completed workout or the first completed weekly goal is a more meaningful threshold: a review request asked before the user has built a habit lands exactly in the "user who hasn't yet grasped the app's value" situation the HIG warns about. In e-commerce, the strongest moment is the notification that an order was delivered successfully — not the checkout screen or the cart page, because there the user is still in a decision phase and can feel interrupted.

I generally prefer looking at two consecutive positive signals rather than a single event: "sync succeeded" alone isn't enough, but "sync succeeded" + "the user opened the result and looked at it for a few seconds" together makes the request feel like a natural continuation rather than a burden. The reverse holds too: a request should never fire right after an error screen, a crash, or two consecutive failed attempts — that would violate both the HIG's warning and plain common sense.

Remember the quota is limited: at most three uses in 365 days on StoreKit, to spend on the three strongest moments. Burn the first one early on a weak signal (e.g. a day after first launch) and you may lose the chance to use a genuinely strong later moment — so logging which events trigger the request in your own analytics layer is the one practical way to manage this.

You can keep the achievement ledger as simply a counter on the code side; the critical point is checking both the threshold count and whether the latest version had an error, before firing the request:

1enum AchievementLedger {
2    private static let counterKey = "successfulEventCounter"
3    private static let threshold = 3
4 
5    static func recordEvent() {
6        let current = UserDefaults.standard.integer(forKey: counterKey)
7        let updated = current + 1
8        UserDefaults.standard.set(updated, forKey: counterKey)
9        if updated == threshold {
10            userCompletedAValueMoment() // The AppStore.requestReview call above
11        }
12    }
13}

So the practical recommendation is: don't try to filter out dissatisfied users before the system prompt; instead, keep a support/feedback channel that's always accessible inside the app, independent of the prompt (a permanent "Contact Us" entry in settings, say). I covered a similar "route the user to the right channel" question in iOS Privacy Compliance and ATT — the same logic explains why a developer can't get ahead of a system-controlled permission dialog either.

Replying to Reviews: Scope and Technical Limits

The Google Play Developer API's "Reply to Reviews" documentation gives concrete, numeric limits for replying to reviews: a read (GET) quota of 200 requests per hour per app, and a reply (POST) quota of 2000 requests per day per app — these quotas apply separately per app, and an increase can be requested if needed. The reply text must be at most 350 characters and plain text — any HTML tags sent are stripped. You can only reply to reviews that contain written text (not star-only ratings). The user is notified only on the developer's first reply, or when the user updates their review — meaning not every reply triggers an instant notification to the user.

Apple doesn't publish a character limit or quota for App Store Connect replies; the only numeric limit we have is the 350-character one on Play's side. My recommendation on scope: keep the reply short, tie it to a concrete fix or release note, and don't copy-paste the same template — the API's 350-character Android limit is already too tight for boilerplate text anyway.

Tracking Rating Drops After a Release

A drop in the aggregate rating average after a new release is a common fear; the HIG explicitly notes that App Store Connect has an option to reset rating history, but that it's risky: resetting "also tends to result in having fewer ratings overall, which can discourage some people from downloading your app." So a reset isn't a "clean slate" — it's a trade-off to use sparingly.

The most solid way to track a drop isn't a "magic tool" but regular monitoring: note the rating average and review volume for the first week after every release, and if you see a sudden drop, first find out which change in that release (a new pricing model, a removed feature, a higher crash rate) triggered it. Reading the relationship between retention trends and rating average together with the cohort logic in Mobile Retention Metrics: D1-D7-D30 makes it easier to answer "is this a real drop or normal fluctuation" — both should be read from a trend over time, not a single day's number.

Forbidden Methods: Why Incentivizing and Filtering Are Risky

There are two official grounds for this. The first is from Android: asking an opinion question, or a leading question, before or while the card is shown is forbidden; a separate CTA button on top of the card isn't recommended either, since once the quota is used up the card never appears and the button becomes a broken experience — route the user straight to the Play Store page instead. The second is from Apple's HIG: repeated, aggressive requests "may even negatively influence people's opinion of your app." App Store Review Guidelines 5.6.1 puts the same prohibition in technical terms: "Use the provided API to prompt users to review your app; … and we will disallow custom review prompts."

Filtering (showing the card only to satisfied users) and incentivizing (a rating in exchange for a discount or credit) are therefore not just "rule violations" but conflict with the API's own design — both platforms present the card the same way to everyone, regardless of segment. I covered Google Play's broader policy-compliance framework in Google Play Policy Compliance Guide; "don't try to manipulate the platform's own mechanism" applies here too.

FAQ

When should the in-app review request be shown?

Show the request right after a concrete event that shows the user has produced real value with the app — in StoreKit's own words, "after a series of events that they successfully complete." Don't show it on the onboarding screen, on first launch, or in the middle of a task; the HIG explicitly flags both as problematic, because the user either hasn't yet grasped the app's value or is currently mid-task and would feel the request as a burden.

How should bad reviews be replied to?

The reply you write through the Google Play Developer API must be at most 350 characters and plain text; instead of copying a template reply, write a short sentence that shows you recognize the issue, ideally referencing a release note or a fix. Remember you can only reply to reviews that contain written text — there's no API option to reply to star-only ratings.

How can the rating average be recovered?

The official sources don't describe a magic "recovery" mechanism; the HIG only mentions the option to reset rating history in App Store Connect, and says it's risky, since it generally reduces the total number of ratings, which can discourage some people from downloading the app. The safer path is fixing the root cause (a crash, a regression, a confusing change) and restarting the value-moment-anchored request in a new, clean release.

Why does the card sometimes never appear on Android?

Because Google doesn't publish the quota value as a fixed number; by its own wording it's an "implementation detail" that can change without prior notice. The card may not show even when launchReviewFlow() completes successfully — your code needs to treat that as a normal possibility, not an error.

Can a user who dismissed the review request be asked again?

On iOS, yes, but with limits: Apple's sample project never makes the call again if the prompt has already been shown for the current bundle version — you need to implement that yourself; you can try again on a different version, as long as you haven't exceeded three within the 365-day window. If the user fully turned off the prompt, the system remembers that choice too. On Android, since the quota is hidden, it's Play Core, not you, that decides the "ask again" timing.

Update (September 2026)

This article was written based on the StoreKit, HIG, and Play Core documentation as of 2025-12-22 (the review-reply limits are taken from the 2025-12-18 revision of the "Reply to Reviews" documentation). Confirmed changes since that date: Google's Play Core "In-App Review" documentation was updated on 2026-01-30, but the quota logic ("implementation detail, subject to change without notice") stayed the same.

Also note: as of 2026-01-31 Apple moved to a new age-rating system for the App Store — this concerns age-appropriateness classification for apps and shouldn't be confused with the star rating/user review topic of this article; the two are entirely separate mechanisms. As of 2026-04-28, apps uploaded to App Store Connect must be built with Xcode 26 and the 26 SDKs; if you're shipping a new release, revisit your review-request timing in that release too. On 2026-03-25 Apple added new cohort capabilities and two monetization peer-group metrics (download-to-paid conversion and proceeds per download) to App Store Analytics; these metrics don't cover rating/review data.

Conclusion

App store rating and review management is a domain where the platform sets the rules, not the developer: StoreKit's quota of three prompts per 365 days, Android's "as-is card" requirement, and the Play Developer API's 350-character reply limit all come down to the same principle — anchor the request to the right moment instead of trying to manipulate it. The achievement-ledger pattern and checklist covered in this article are the shortest path to gathering genuine feedback without wasting the quota.

If you want to read this topic in a broader context: App Store Optimization (ASO) covers the acquisition/ranking side, Push Notification Permission Rate Optimization covers the shared timing logic of system permission prompts, iOS Privacy Compliance and ATT covers the limits of system dialogs, Mobile Retention Metrics: D1-D7-D30 covers reading trends, and Google Play Policy Compliance Guide covers complying with platform rules.

Sources

• Requesting App Store reviews — Apple Developer — the primary source for StoreKit's max-3-prompts-per-365-days quota and the sample project's per-version repeat-prevention condition.
• Ratings and Reviews — Human Interface Guidelines — Apple's official design guidance on when the request should and shouldn't be shown, the risks of resetting ratings, and the negative effect of repeated requests.
• In-app review API — Android Developers — Play Core's card design, trigger timing, and hidden/variable quota rules.
• Respond to reviews — Google Play Console Help / Developer API — the GET/POST quotas for replying to reviews, the 350-character limit, and notification behavior.
• App Store Review Guidelines — Apple Developer — the official policy text containing the ban on forced reviews (3.2.2 x) and the "paid, incentivized, filtered, or fake feedback" prohibition at the start of guideline section 3, Business.
• Upcoming requirements for app submissions — Apple Developer — the source for the 2026 age-rating and SDK requirement dates (for the Update section).