Ratings and reviews influence whether people install your app, and they tell you what to fix. But the way you ask matters. Done carelessly, a review request annoys users, breaks store rules, or produces a skewed picture. This guide explains the official in-app review mechanisms, when to trigger them, what to avoid, and how to respond to what comes back.
Review mechanics and policies are updated by the stores. Where this article describes behaviour, confirm it against the current documentation for the In-App Review API on Android and the review request APIs on iOS, and read the ratings and reviews policies in Play Console and App Store Connect.
Use the official in-app prompts
Both platforms provide a system-controlled dialog that lets a user rate the app without leaving it.
- Google Play: the In-App Review API. Your app requests a review flow and then launches it; Google Play decides whether to show a dialog.
- Apple:
SKStoreReviewController(and the newer review request APIs described in Apple’s documentation). The system decides whether and when to display the prompt.
In both cases, the platform controls the display and limits how often it appears. You cannot know whether the user rated, dismissed, or never saw the dialog, and you should not try to find out. Treat the call as a request, never as a guarantee, and do not attach it to a button labelled “Rate us” that appears to do nothing when the system suppresses the dialog. If you want a visible “Rate this app” link, such as in settings, send users to the store page with a standard store link, where they can write a review directly.
Never build your own fake rating dialog that mimics the system one, and never pre-select a star value. Both are misleading.
Pick the right moment
Timing decides whether the prompt feels natural or intrusive. A good moment follows a success the user will recognise:
- They completed a meaningful task, for example finishing a lesson, exporting a file, or reaching a goal.
- They have used the app repeatedly over several sessions, showing real engagement.
- They are in a calm state between activities, not in the middle of something.
Bad moments include:
- At first launch, before the user has had any value.
- Right after a crash, an error, or a failed purchase.
- During onboarding, a payment flow, or a time-pressured task.
- Immediately after the user dismissed a different prompt.
- While an ad is on screen.
Write down the rule for your app in plain language, for example “after the third completed task in separate sessions, and not more than once per version.” Then implement it with a counter stored locally. Do not invent thresholds from nowhere; start with something modest, observe feedback, and adjust.
Do not incentivise reviews
Offering a reward in exchange for a rating or review is against both stores’ policies. That includes:
- Money, coupons, or in-app currency.
- Unlocking features or removing ads.
- Entry into a giveaway.
- Removing a limit or an annoyance for people who say they reviewed.
Even soft versions, such as “help us stay free by rating five stars”, pressure users toward a particular score. Ask for honest feedback and leave it there. Confirm the specifics of the current policy before launching any campaign.
Do not gate by sentiment
A popular pattern asks “Are you enjoying the app?” and then sends happy users to the store and unhappy ones to a private feedback form. This is called review gating, and the stores discourage it because it distorts ratings. Alternatives that keep you on the right side:
- Show the system prompt to everyone who meets your timing rule, regardless of mood.
- Offer a separate, clearly labelled “Send feedback” option in settings or help, available at all times, for people who want to reach you privately.
- Make feedback and rating paths independent, so that a negative response to one does not change what the user sees in the other.
Check the current wording of the policies in each developer console, since the line between a feedback question and gating is something the stores define.
Ask in the user’s language and tone
Keep copy short and polite. If you show a pre-prompt of your own at all, make it neutral and let the user dismiss it with no penalty. Do not use guilt, urgent language, or misleading text. Localise it along with the rest of the app. For sensitive categories, such as health apps, avoid wording that implies a result or endorsement.
Reply to reviews
Replying shows that someone is paying attention, and it is public, so other visitors read it.
- Thank them briefly and without a script. Template-sounding replies look like automation.
- Address the specific point the reviewer made. If you know the cause, say so.
- Offer a path to help such as a support address, but do not request private information in a public reply.
- Say when a fix ships only if you are sure. An unfulfilled promise is worse than no promise.
- Keep it calm. Never argue, shame, or get defensive.
- Update the reply when the issue is fixed, since a reviewer may be notified and may revise a rating.
Both consoles let you reply and filter reviews. Build a routine, such as a short daily or weekly pass, and assign it to a specific person. If you run many apps, the portfolio checklist describes how to keep review monitoring organised.
Handling negative reviews
Negative reviews are information. Sort them into groups:
- Bugs and crashes: compare with your crash reports, then fix and reply.
- Missing features: log the request in your tracker and consider whether it fits the product.
- Misunderstandings: the app may work correctly but explain itself poorly. Improve onboarding and the listing text.
- Billing or ads complaints: check that your purchases and ad placement behave as described. A heavy-handed ad experience will show up here first.
- Abuse or off-topic content: use the console’s reporting tool for reviews that violate the policy, rather than replying in kind.
Do not ask a reviewer to delete or change a review as a condition of help. You may invite them to update it after the problem is resolved, but the decision is theirs.
Measure what matters
Track trends over time rather than a single number: average rating by version, share of reviews mentioning a particular issue, and reply rate. Do not tie a developer’s bonus to the average rating, since that creates pressure to game the system. Treat reviews as one input alongside crash analytics and support emails.
A better rating also helps conversion on your listing, which links to the work described in app icon and screenshot practices and the wider organic installs checklist.
Implementation notes
- Keep a local counter of qualifying events and a record of the last version for which you requested a review.
- Wrap the review call in error handling. It may fail, return nothing, or be throttled.
- Test with the tooling provided by each platform, such as internal test tracks on Android, so you do not request reviews from real users during development.
- Log the request event for your own analytics without storing anything about the outcome of the dialog.
More guidance for app owners is in the publishers hub.