How a rating prompt should look and where to place it
A rating prompt is a tiny piece of interface that can quietly cost you users or quietly earn you ratings. Timing is covered in when to ask for app reviews. This article is about what the request looks like and which screens it belongs on.
Use the native dialog
Both platforms offer a system dialog that lets a user rate without leaving your app. It looks familiar, takes one or two taps and keeps the user in context.
- iOS: request a review through the system API provided by StoreKit. Apple's App Review Guidelines say to use that API for rating requests rather than a custom prompt, so check the current wording before shipping anything else.
- Android: use the Play In-App Review API. It shows a bottom sheet and lets the user rate and write a review without going to the store.
What a native dialog looks like is decided by the system. You do not control the text, the colours or the exact moment it appears, and the system may decide to skip it. That is a feature: it is consistent and trusted.
What to build yourself
You control what happens before the system dialog and the permanent route to the store:
- A calm trigger. A success screen or a quiet moment, never an interruption.
- A separate "Rate this app" row in settings or the about screen. It opens the store page directly for people who want to rate on purpose. It never needs a conditional dialog.
- A private feedback entry for everyone: "Something wrong? Tell us." A short form, an email link or a message to support.
Do not simulate the system dialog with your own stars. A look-alike confuses users, can be rejected in review and sets expectations the store cannot meet.
Where to place it
Rank screens by how good the moment is:
| Screen | Good place? | Why |
|---|---|---|
| Result or success screen, after the main action | Yes | Value just delivered. |
| End of a session, when the user is about to leave | Often | Calm, nothing is interrupted. |
| Home screen after several days of use | Maybe | Only with usage thresholds. |
| Paywall, onboarding, permission request | No | The user is making a decision. |
| Error and crash recovery screens | No | Unhappy by definition. |
| Mid-task (typing, playing, checking out) | No | An interruption. |
A simple rule: if the screen could carry the headline "Done!", it is a candidate.
A prompt you can model in your own words
Since the system dialog is fixed, the wording you control lives in your own screens around it:
- Success screen headline: "Your report is ready."
- Subtle follow-up row below it, not a modal: "Enjoying the app? You can rate it in the store." A tap on the row then calls the system dialog.
- Settings row: "Rate this app" with a chevron.
- Feedback row: "Report a problem or suggest a change."
Keep wording honest and neutral. Do not say "Please give us five stars" or hint at the answer you want, and never reward a rating.
Accessibility and polish
- Everything reachable by keyboard and screen reader.
- Large tap targets and clear labels.
- No fake countdowns, no guilt copy ("Don't you like us?").
- A clear way to dismiss without penalty. A dismissed prompt should not return for a long time.
Test the placement
Ask a few people to use the app and tell you when the prompt interrupted them. Fellow developers are quick at this; on AppReviewX you can ask testers to note where in the flow a prompt felt wrong. Then compare the share of prompts followed by a rating, and your average rating, before and after any move.
Checklist
- Native dialog only for the request itself.
- Triggered after a success moment.
- Separate settings row for deliberate ratings.
- Private feedback route for everyone.
- No custom star widgets imitating the store.
- No rewards, no pressure wording.
- Test where it interrupts, then adjust.
Need testers for your app? Open a test group on AppReviewX. Start free