When to Prompt Users to Rate Your App

TL;DR

Your star rating is one of the strongest levers on install conversion, and the only reliable way to raise it is to ask happy users at the right moment. Apple caps you at three prompts per user per year and Google throttles quietly, so the ask is a scarce resource. Trigger it right after a user completes something that felt good — a finished workout, a saved file, a fifth successful session — and never after a crash, a paywall, a permissions denial, or a support ticket. Get the timing right and the same prompt that used to earn you two-star complaints starts earning you five-star reviews.

What a star is actually worth

I've watched an app sit at 3.9 stars for months, then climb to 4.6 without a single new feature shipping. Nothing changed except when we asked people to rate it.

The reason that matters is that the star rating does two jobs at once. It's a ranking input — both stores factor rating volume, average score, and how recent your reviews are into where you land in search results. And it's a conversion input, arguably the bigger one. A person searching the App Store sees your icon, your title, and a number with stars under it, in that order, before they read a word of your description. That number is the fastest trust signal in the entire storefront. The difference between 4.6 and 3.8 shows up in your install numbers long before it shows up in your ranking.

Here's the trap. Most apps have a rating problem, not a quality problem. The people who love your app open it, use it, and close it. They feel no particular urge to write anything down. The people who hate it — the ones whose subscription auto-renewed, whose export failed, whose account got locked — those people are motivated. They will find the review form unprompted. Left alone, your rating becomes a survey of your angriest users.

The prompt exists to correct that sampling bias. It's not a growth hack; it's a way of giving your quiet, satisfied majority a two-second path to being counted. But it only works if it reaches them while they're actually satisfied.

You get about three asks a year — spend them like it

This is the part I wish I'd understood earlier, because it reframes everything else.

On iOS, SKStoreReviewController doesn't guarantee anything. You request a review; the system decides whether to show it. Apple caps the display at three prompts per user per app per 365-day period, and any user can switch off in-app ratings entirely in their App Store settings. Google's In-App Review API works the same way — you launch the flow, and the API decides. Google doesn't publish its quota numbers, but it throttles, and it fails silently when you're over.

So you don't have a rating prompt. You have a budget of roughly three, per user, per year — and no confirmation of when you've spent one. That's why the "ask everyone on the third launch" approach is so expensive. You burn an ask on someone who's been in the app for four minutes and has no opinion yet, and if they do respond, they respond to a first impression rather than a formed one.

Both platforms also come with rules that people break constantly. Apple's guidance is not to trigger the prompt from a button or any explicit user action — if you want a "Rate this app" button in your settings screen, it should deep link straight to the store's write-review page instead, using a URL that ends in ?action=write-review. Google is more explicit still: don't ask users a qualifying question before showing the review flow, don't trigger it from a button, and don't offer anything in exchange for a rating. Incentivized reviews are a policy violation on both stores and a good way to get reviews stripped.

The upshot: the prompt has to be something you decide to show, based on behavior you've observed, at a moment you chose. That's a product decision, not a marketing one.

Ask right after a win

The best moment to ask is the instant after a user has finished something and feels a small flush of accomplishment. Call it the moment of delight, the payoff moment, the aha — the name doesn't matter, the shape does. Something the user was trying to do just worked.

What that looks like depends entirely on the app:

• A fitness app should ask after a completed workout, not when someone opens it at 6 a.m. still deciding whether to go.
• A photo editor should ask after a successful export and share, not after the fifth failed attempt at a mask.
• A budgeting app should ask when someone hits a savings goal or finishes categorizing a month.
• A language app should ask after a streak milestone — day 7, day 30 — when the user is already feeling good about their own discipline.
• A utility should ask after the third or fourth successful, uneventful use, when the habit has formed and nothing has gone wrong.

The pattern underneath all of these: the user just got value, and they know it. You're not interrupting a task, you're punctuating a completed one. That's why the exact same prompt can produce wildly different average scores depending on where it fires. You're not measuring the app's quality. You're measuring the emotional state of whoever you caught.

There's a second layer worth adding: proven engagement. A moment of delight on day one is thinner than the same moment on day fourteen. Someone who has come back six times and completed the core action four times has actually formed an opinion, and their review will be more specific, more credible, and more likely to mention the features you care about. Reviews that describe real use also help you in search — they naturally contain the language your future users type into the search bar.

The moments that quietly cost you stars

Knowing when not to ask matters more than knowing when to ask, because a badly timed prompt doesn't just get dismissed. It converts a mildly annoyed user into a one-star review that will sit on your listing for a year.

Never ask in the same session as a crash or a hard error. If your app force-closed, failed to sync, or lost someone's work in the last few minutes, that user is disqualified for at least a few days.

Never ask immediately after a paywall — before it, during it, or in the moments after someone declines. You've just asked for money; asking for a favor in the same breath reads as tone-deaf. The same goes for the moment after a permissions denial. Someone who just declined notifications is telling you they want less from you, not more.

Never ask mid-task. If a user is halfway through composing, editing, checkout, or onboarding, a modal is an obstacle, and they will rate the obstacle.

Never ask a user who has just contacted support, submitted a bug report, or started a cancellation flow. These people are in a negotiation with you. Put them on an exclusion list and let the ticket resolve first — if it resolves well, they become excellent candidates a week later.

And be careful with the ask right after a big update. New builds are where regressions live. Give a release a few days to prove itself before you point your entire happy-path funnel at the review form.

There's one more thing worth being clear about, because it's a common shortcut. Many apps run a pre-prompt: "Are you enjoying the app?" with a thumbs up leading to the store prompt and a thumbs down leading to a private feedback form. Google's policy prohibits it outright, and Apple's guidelines discourage interrupting users with custom review requests. Beyond compliance, it burns a step of the user's patience before you've asked for the thing you actually want.

The better version of that idea is a permanent, easy-to-find feedback path that has nothing to do with the rating prompt — a support link in settings, a "something wrong?" entry point after an error, a short survey in your cancellation flow. Unhappy users need somewhere to go. They just shouldn't be routed there by a gate standing in front of the review form.

A trigger rule you can ship this week

Here's a starting point that works for most apps, and that you can tune once you have data:

Show the prompt when all of these are true: the user has completed your core action at least three times; at least five days have passed since install; the current session ended in success, not error; there's been no crash, failed transaction, or support contact in the last seven days; and you haven't shown the prompt in the last 90 days.

That last one is the piece most teams skip. Because neither platform tells you whether the prompt actually appeared, you have to keep your own counter locally — a timestamp for each request you made and a count for the rolling year. Without it, you'll spend all three of your annual asks in the first month and have nothing left for the user's second year, which is exactly when their review is most valuable.

Then place the ask carefully within the moment. Not as a modal that lands on top of a success animation, but a beat after it — a second or so, once the confirmation has registered. Let the user experience the win first, then ask.

If you operate in multiple markets, remember that ratings are counted per storefront. An app with 4.8 stars in the US can be sitting at 3.9 in Germany or Brazil, because the prompt logic was tuned for one audience and never localized. Check each market separately, and prioritize the ones where you're actively trying to rank.

How to tell if it's working

You can't attribute individual reviews to individual prompts — the stores don't expose that, by design. So measure the aggregate.

Track how many prompt requests you fire per week, and watch your review velocity against it. The metric that matters is new ratings per thousand active users, not total count, because total count only ever goes up. Watch your rolling 30-day average score separately from your lifetime score; the lifetime number moves too slowly to teach you anything.

Then make one change at a time. Move the trigger from launch to post-completion and hold it for a month. Raise the engagement threshold from one core action to three and hold it for a month. You'll usually find that the change in average score is bigger than any change in volume — which is the point. Fewer, better-timed asks beat more asks.

Watch your one-star reviews too, specifically their timestamps and content. If a cluster shows up complaining about being nagged, your trigger is firing too early or too often, and no amount of clever copy will fix it.

The ask is a product decision

Rating prompts get filed under marketing, and that's the mistake. Where you place the ask depends on knowing exactly where in your app people feel good — which is the same question as knowing whether your app is any good.

If you can't identify the moment of delight to hang the prompt on, that's the finding. Go build one first. Once you know what it is, the prompt takes an afternoon to wire up, and it's probably the highest-leverage afternoon on your roadmap this quarter.