What the Data Actually Says About iOS Rating Prompts

Apple's native rating prompt fires at most three times a year per user, per app — and you don't control when, only when you request it. Many teams try to work around this with "gating," which Apple's own guidelines treat as review manipulation. Here's what's actually effective and actually allowed.

The iOS rating prompt (SKStoreReviewController, now StoreKit's `requestReview` API) is deceptively simple to call, but the system it sits inside has real constraints most teams don't fully account for: a hard frequency cap you don't control the exact timing of, and a policy line around "gating" that a surprising number of ASO guides recommend crossing.

The mental model: you request, the system decides

Calling the review-request API doesn't guarantee a prompt appears — it's a request, and the system uses its own logic (including the once-per-365-days-times-three cap, and internal heuristics about whether now is a good moment) to decide whether to actually show it. This means the meaningful lever you control isn't frequency of asking — you're capped regardless — it's precision: making sure the requests you do make land on genuinely good moments, since you get very few real opportunities per user per year.

Gating: why it's common advice and why it's against the rules

"Gating" refers to showing your own custom dialog first — "Enjoying the app?" — and only triggering the native review request if the user answers positively, routing unhappy users to a private feedback form instead. It's a genuinely common pattern in ASO advice, and it's also explicitly the kind of practice Apple's guidelines treat as review manipulation: pre-filtering who gets asked to leave a public rating based on their sentiment skews the visible rating distribution away from what a truly representative sample of users would produce. This is a real compliance risk, not just a stylistic preference — it isn't the same category of violation as fake reviews, but it sits inside the same guideline concept of manipulating the review system's integrity.

What "good timing" actually means without gating

Since you can't ethically pre-screen for happy users, the alternative is to infer likely satisfaction from behavior you already have — not from asking directly. Firing the request after a user completes a meaningful positive action (finishing a task, hitting a usage milestone, successfully completing a purchase or workflow) is a legitimate, non-gated way to bias toward good moments, because you're using objective in-app signals rather than a subjective pre-screen with a routing decision attached. The distinction that matters to Apple's guideline isn't "did you think about timing" — thoughtful timing is encouraged — it's "did you build a mechanism that filters who gets asked based on their answer to a satisfaction question."

Try it: does this pattern gate the prompt?

Why the frequency cap exists in the first place

Apple's rationale for capping how often the native prompt can appear is straightforward: an interruption asking for a rating is a real cost to the user experience, and without a hard platform-level limit, individual apps would have every incentive to over-ask, degrading the experience across the whole App Store. This is worth internalizing as a design constraint rather than a technical inconvenience to route around — the cap exists because unlimited asking, in aggregate across every app doing it, would make the prompt itself less meaningful and more annoying, which is exactly the failure mode gating and over-triggering both risk recreating at the individual-app level even within the cap.

What happens to requests the system declines to show

When you call the request API and the system decides not to show a prompt — because the cap has been hit, or because its internal heuristics determine it isn't a good moment — the call simply does nothing visible, silently. This matters for how you should interpret in-app analytics: if you're tracking "review prompt requested" as an event, that event firing doesn't mean a user actually saw a prompt, so conflating "requested" with "shown" in your own funnel analysis will overstate how often the rating flow is actually reaching users. If you want a more accurate picture of impact, correlate prompt-request timing with actual App Store rating and review volume changes over a longer window, rather than trusting your own client-side "requested" event as a proxy for "shown."

The three-per-year budget, spent deliberately

Because the system caps requests at three per year regardless of how many times you call the API, calling it too early or too often within that window doesn't get you more prompts — it just risks spending one of your few real opportunities on a mediocre moment. A deliberate strategy: identify your single strongest, most reliably positive in-app moment (not several mediocre ones), request there first, and only add a second trigger point if you have real evidence the first one isn't catching most eligible users. Spreading requests across many possible trigger points, hoping one lands well, tends to waste the scarce budget rather than protect it.

Worked example (illustrative)

Illustrative: request timing vs. prompt effectiveness

A compliant rating-prompt checklist

• Identify your single strongest objective positive-moment trigger before writing any code.
• Never build a custom pre-screen dialog that routes users differently based on their answer before the native prompt.
• Keep in-app feedback surveys entirely separate from the rating-request flow, not sequenced into it.
• Don't over-call the request API expecting more prompts — the system caps it regardless, so precision matters more than frequency.
• Review your trigger logic periodically as the app changes — a milestone that was meaningful at launch might not be anymore after a redesign.

How this compares to Android's rating flow

Google Play's in-app review API operates on a broadly similar philosophy — developers request a review flow, and the platform decides whether and how to show it, with its own frequency safeguards to prevent over-asking. The same core principle carries across both platforms even though the exact mechanics differ: neither platform wants developers to have unrestricted control over when a rating prompt appears, precisely because unrestricted control creates the incentive to game it. If you're building a rating-prompt strategy for a cross-platform app, it's worth designing one shared "what counts as a good moment" framework based on objective in-app signals, then implementing platform-specific calls against that shared framework — rather than developing two separate ad hoc timing strategies that might drift into gating on one platform without you noticing, since gating pressure tends to creep in when a team is optimizing platform-by-platform rather than against a single stated principle.

Common mistakes

• Building a gating flow because it's common advice. Popularity of a tactic doesn't mean it's compliant — this one is explicitly against Apple's guidelines.
• Requesting a review immediately on first app open. There's no positive signal yet to justify the timing, wasting one of very few yearly opportunities.
• Assuming more API calls means more prompts shown. The system's cap is independent of how often you call the request method.
• Treating in-app satisfaction surveys and rating requests as the same flow. Keeping them separate avoids both the compliance risk and a confusing user experience.

Auditing an existing rating-prompt implementation

If you're inheriting a codebase rather than building this from scratch, it's worth an explicit audit rather than assuming existing logic is compliant. Search the codebase for every call site of the review-request API and trace backward: is the call gated behind any custom dialog or sentiment check, or does it fire unconditionally for all users reaching that code path? Check whether there's any branching logic that routes based on a prior in-app rating or feedback answer specifically before the request call — that branching is the signature of a gating pattern, even if it's not labeled as such in the code or documented anywhere. This kind of audit is worth doing once deliberately rather than assuming "it's probably fine" just because the app hasn't had a review-guideline issue yet — Apple's enforcement here isn't necessarily immediate or consistent, which means an existing gating pattern can sit unnoticed for a long time before it becomes a problem.

TL;DR

If your app currently uses a gating pattern, treat this as a real compliance risk worth reviewing, not just a best-practice suggestion — it falls under Apple's review-manipulation guideline.