Your app’s rating is one of the strongest conversion factors on the App Store. A jump from 3.5 to 4.0 stars can increase downloads by over 30%. A jump from 4.0 to 4.5 can push it even higher. Yet most indie creators either never ask for reviews or ask at the worst possible moment.
The timing of your review request is the difference between a 4.8-star rating and a wall of one-star complaints.
Users are most generous with ratings when they’re feeling good about your app. That sounds obvious, but most apps ignore it completely. They ask after the user has been using the app for a week, or they trigger a random popup during a session. By then, the initial excitement is gone. The user is in utility mode, not discovery mode.
The best time to ask is right after a moment of delight, when the user just accomplished something for the first time and feels good about it.
This sounds counterintuitive. The user just got here. Why would they rate the app?
Because during onboarding, hype is at its peak. The user is actively engaged, tapping through screens, discovering features. If your onboarding includes a moment of real value. They created something, saw a personalized result, completed a first task, that’s a natural place for a review prompt.
The logic: if they don’t pay at the paywall, at least get a review from them. You either monetize the user or you get social proof from them. Nobody should leave your onboarding without giving you one of those two things.
Every good app has a moment where the user thinks “oh, this is cool.” In a photo editor, it’s when they see the first filter applied. In a fitness app, it’s completing the first workout. In a creative tool, it’s seeing their first creation come to life.
That moment, not five minutes later, not the next day. Is when you ask. The emotional peak is short. Capture it.
Don’t send every user straight to the App Store rating prompt. Use a pre-review screen that asks something like “How’s your experience so far?” with two options:
Positive response (“Love it!” or 4-5 stars): Trigger the official App Store review prompt via SKStoreReviewController. These users will leave good ratings.
Negative response (“Not great” or 1-3 stars): Send them to a feedback form instead. This catches complaints before they become public one-star reviews. You get the feedback, the user feels heard, and your public rating stays clean.
This isn’t manipulation, it’s routing. Happy users rate publicly. Unhappy users get a direct channel to you. Both groups get a better experience.
Apple has strict guidelines for review prompts:
Three times per year. You can only call SKStoreReviewController.requestReview() three times within a 365-day period. Apple may not show the prompt every time you call it, either, the system decides.
No custom review popups. You cannot build your own “Rate us on the App Store” modal that links directly to your App Store page. You must use Apple’s API. Your pre-review satisfaction screen is fine because it doesn’t link to the store. It just decides whether to trigger Apple’s prompt.
No incentives. You cannot offer rewards, discounts, or unlocked features in exchange for a review. “Rate us and get 50 free credits” will get your app rejected.
If you don’t want to ask during onboarding, the second-best approach is milestone-based triggers:
The common thread: every trigger is tied to a positive action, never a neutral or negative one. Never ask after an error, a crash, a failed payment, or a long loading screen.
Review prompt acceptance rate: What percentage of users who see the prompt actually leave a review? Industry average is around 3-5% of prompted users.
Rating distribution: Are you getting mostly 4-5 stars? If your average is below 4.0 after implementing these strategies, the problem isn’t timing, it’s the app.
Satisfaction gate routing: What percentage of users go to the positive path vs. the feedback path? If most users hit the negative path, you have a product problem, not a review problem.
Asking at the right moment gets you the rating. What you do with it afterwards is a separate decision, and the apps that treat the rating as an asset rather than a vanity number place it very deliberately.
Runna and QUITTR · the count does the work, not the score
Runna leads with “30,000+ reviews”. QUITTR shows 4.8 from 140,000 users. In both cases the volume is carrying more weight than the score, because almost every app claims something above 4.5.
A high score with no count attached is the weakest form of this. If you have the volume, the volume is the claim.
Moonly · three kinds of proof before any price
Press mastheads, then 31,000 reviews, then Apple's Editor's Choice badge, all placed before the plan appears.
Editor's Choice is worth surfacing because you cannot buy it, which is exactly why readers weight it differently from a star average. It backfires when press logos are decorative and the coverage does not exist.
TIDE and Me+ · the badge as a single unit
TIDE pairs Editor's Choice with a 130K review count. Me+ compresses a 4.9 rating into a laurel badge that reads as one object rather than as a row of numbers.
Compressing proof into a single recognisable shape means it survives being glanced at, which is how paywalls are actually read.
BitePal · when a named result beats a rating
A named customer with a measured outcome, 67 kg to 62 kg in one month, sitting alongside the 4.7 rating rather than instead of it.
The rating says people like the app. The named result says the app does something. Those are different claims and the second one is harder to earn, which is why it converts better when it is true.
The practical point for timing: ask after a success the user can name, because that is also the review most worth displaying later. A five-star review that says nothing is a number. One that names an outcome is copy you can use.
SKStoreReviewController (not custom modals)At high hype and low friction: right after a moment the user experienced as a success, and never in the middle of a task. The satisfaction gate exists so that you only ever ask people who have already signalled they are happy.
Apple caps the native prompt at three times per user per year, and you do not control whether it actually appears on any given call. That is why it is worth spending those attempts on your strongest moments rather than triggering on app open.
After, and after the user has actually got something out of the app. Asking before you have delivered anything converts badly and spends one of your three prompts on a user with nothing to say yet.
Reading about it is one thing. Knowing which change is worth making on your funnel, and what it is costing you today, takes a look at your numbers. I’ll do that and tell you what I’d fix first.
See App OptimizationConversion design for app creators. Screenshots, paywalls, onboarding — one funnel, not three projects.