In-App Review Prompts: Timing and Limits
A lot of developers assume something's broken when their in-app review popup doesn't show up on cue. In reality, both Google and Apple deliberately designed these prompts to not always fire. This post covers how Google Play's In-App Review API and iOS's request-review API actually behave, why you shouldn't wire a CTA button directly to them, and when the industry generally considers good timing to ask. Once you've got replies coming in, see our store review reply guide for how to handle them.
Google Play's In-App Review API: not showing up can be normal
The official docs state plainly that calling this API doesn't guarantee the dialog appears. Google Play enforces a time-bound quota for the sake of user experience, and the docs call this quota an "implementation detail" — meaning the exact number isn't published and can change without notice. The one example given is that calling launchReviewFlow repeatedly within a short window (say, less than a month) might not always produce a dialog. There's no specific "X times per Y days" figure you can state as fact.
UI customization is off the table too — the dialog has to use the system's default design as-is. Gating the prompt behind a satisfaction question ("Are you enjoying the game?") before asking for a review also violates the guidelines. Just as important: the official docs actively discourage building a dedicated CTA button to trigger this flow, since a user who's already hit their quota would tap it and see nothing happen — a dead button. For that use case, the recommendation is to deep-link straight to the Play Store listing instead.
There are two ways to test it. Installing through Internal App Sharing or the internal testing track lets you see the dialog UI, but the actual submit button is disabled. For code-level testing, there's FakeReviewManager, which doesn't simulate the UI at all — it only simulates the API call's result (success/failure, the ReviewInfo object) for unit and integration tests. If you're building in Unity, Google officially maintains the com.google.play.review package for this, which brings in the Play Core library and EDM4U (External Dependency Manager) as dependencies.
iOS: an automatic 365-day, 3-time cap
iOS uses SKStoreReviewController (or SwiftUI's RequestReviewAction) to trigger a prompt. Apple's official RequestReviewAction documentation spells out exactly when the dialog appears: if the user hasn't rated or reviewed the app on that device yet, it can show up to 3 times within a 365-day period; if the user has already rated or reviewed it, it only shows again once a new app version has shipped and 365 days have passed since the previous review.
Behavior also differs by build environment, and this too is documented, not just observed. Both the SKStoreReviewController.requestReview() documentation and the RequestReviewAction page above state that during development (debug builds) the prompt displays every time you call it, and that the request has no effect at all in beta apps distributed via TestFlight. In other words, the dialog not appearing in TestFlight isn't a community-observed quirk — it's documented Apple behavior. The real frequency throttling only kicks in once you're in a production, App Store–distributed build.
What Apple's guidelines actually say
App Review Guideline 5.6.1 directly addresses how you're supposed to ask for reviews: it says to use the provided API to prompt users, and explicitly states that custom review prompts are not allowed. In other words, building your own "please rate us" screen is itself a guideline violation, regardless of timing. 5.6.3 separately bans manipulating any App Store experience element — charts, search, or reviews. For incentivized reviews specifically, the opening of Section 3 (Business) states that manipulating ratings or rankings with paid, incentivized, filtered, or fake feedback can get a developer expelled from the Apple Developer Program. This is sometimes misattributed to a section numbered 2.3.13, but that section actually covers in-app events and has nothing to do with reviews — worth not conflating the two.
Google Play's policy is aligned here too: its user ratings, reviews, and installs policy explicitly bans incentivizing reviews or ratings with money or rewards. "Leave 5 stars, get free coins" is a violation on both stores.
What counts as good timing
Neither guideline dictates exact timing, but there's a fairly consistent industry practice: ask right after the user has just had a positive experience.
- Right after clearing a level or stage
- Right after earning a new reward or item
- Right after finishing the tutorial and hitting a first achievement
- For users who've opened the app several times in a row (say, on their 3rd to 5th session)
Conversely, it's best to avoid asking right after the first tutorial screen, right after a loading moment, or right after an error — anywhere the experience just went badly. This is all empirical industry practice, though, not an official rule from Google or Apple about exactly when to fire the prompt.
What to do when the popup is quota-blocked
If you still want to give users who got skipped by the quota a path to leave a review, one option is a deep link to the store listing tucked into a settings screen or profile page. On Android, a market://details?id=your.package.name URI opens the Play Store app directly; on iOS, it's common to append a parameter to the App Store listing URL that jumps straight to the write-a-review screen. Since this routes the user through the store itself rather than the In-App Review API, it sits outside the CTA-button restriction in the guidelines — and Google's own docs recommend exactly this pattern for that use case.
Wrapping up
An in-app review popup not showing up on demand is, more often than not, working as intended. Google manages this through a quota and Apple through its automatic 365-day/3-time cap, and the only real lever a developer has is when to call the API in the first place. Forcing it through a CTA button, or gating it behind a satisfaction question, violates both platforms' guidelines — so the safest approach is to call the API right after a genuinely positive moment and leave the rest to the system.