Ratings and reviews prompt App Review checklist

Choose a real value moment

Trigger review requests after the user completes a meaningful task: finishing a report, saving a project, completing a workout, resolving a review checklist, or receiving useful output. Do not ask during onboarding, error states, purchase failures, or account deletion.

A prompt shown too early can train users to dismiss it and can make the product feel more interested in ratings than outcomes.

Avoid coercive patterns

• Do not gate features, rewards, support, or content behind ratings.
• Do not ask only happy users while hiding review paths from unhappy users in a manipulative way.
• Do not interrupt safety, payment, login, or support workflows.
• Respect system prompt behavior and avoid custom dark-pattern copies.
• Route complaints to support without blocking access to App Store review options.

Separate support from ratings

A user with a broken purchase, login failure, or safety issue needs help, not a review prompt. Add support entry points near failure states and reserve rating prompts for successful outcomes.

AppReviewReady interpretation: reputation growth is strongest when it follows product value. Prompt timing should be part of release QA, not a last-minute growth hack.

Measure prompt quality

1. Track prompt eligibility locally without storing sensitive user content.
2. Compare ratings, support tickets, refund reasons, and task completion after prompt changes.
3. Test prompt suppression after crashes, failed payments, or repeated errors.
4. Review localized prompt copy and support links.
5. Pause prompts during incident response or major migrations.

Rating prompt map

The map keeps rating growth connected to user success. It also makes prompt changes reviewable when product teams experiment.

After launch, read reviews as qualitative SEO and conversion research. Repeated language from reviews can inform landing pages, guide topics, and paid-report positioning.

If the app has a paid report, subscription, or high-value workflow, avoid prompting before the user has seen the paid value. Asking too early can attract ratings from people judging setup friction rather than the product outcome.

Build suppression rules for vulnerable moments: after a failed checkout, rejected login, denied permission, safety warning, or support escalation. These users need resolution before reputation asks.

For teams running experiments, change one prompt variable at a time: moment, copy, delay, or eligibility. Otherwise ratings movement cannot be tied to a real product decision.

Keep prompt logic out of critical review paths. A reviewer testing purchases, deletion, or safety reporting should not be interrupted by reputation UX.

Prompt map:
Value moment: [event]
Delay/frequency: [rule]
Suppression states: [errors]
Support alternative: [path]
StoreKit API path: [screen]
Measurement: [metric]
Owner: [team]