Ratings and reviews influence more than a number on the product page. Apple says they appear in search and can influence how an app ranks. They also shape a potential customer’s decision and expose mismatches between the listing and the installed experience.
The goal is not to manufacture five-star sentiment. It is to create an experience worth rating, ask at an appropriate moment, and respond to real feedback in a way that helps both the reviewer and everyone reading later.
There is no honest promise that a prompt will produce a particular rating, review count, conversion lift, or ranking change.
Know what Apple displays
Customers can leave a one-to-five-star rating and, on supported platforms, a written review. The product page shows an overview rating for each App Store country or region together with customer reviews. Apple also provides review summaries for eligible apps and devices.
A rating and a written review are related but different:
- a rating contributes to the displayed overview score;
- a review includes public text that customers and the developer can read;
- a developer response is public, not a private support ticket;
- when a developer responds, Apple notifies the reviewer, who can update the review.
This country-specific context matters. Do not use one global average to diagnose a localized pricing, translation, reliability, or support issue.
Earn the moment before asking
Apple’s Human Interface Guidelines recommend asking only after people have demonstrated engagement, such as completing a meaningful task or level. The best trigger represents satisfaction with the product’s core value—not simply survival through onboarding.
Examples of plausible moments:
- a document app successfully exports the third file;
- a workout app records a completed plan;
- a game completes a level or meaningful achievement;
- a scanner produces and saves a readable result;
- a finance app completes a useful setup milestone without an error.
Avoid asking:
- immediately after launch;
- during a task or transition;
- after a crash, failed payment, support request, cancellation, or permission denial;
- at the end of onboarding when the user has not experienced value;
- every time the trigger happens;
- only after a custom “Are you happy?” gate identifies likely positive reviewers.
Define the eligible moment in product terms:
The user completed the core action at least twice, the current session contains no error, the app has not requested a review for this version, and the user has been on the success state long enough not to be interrupted.
The exact thresholds should fit the app. Apple’s sample uses repeated task completion as an illustration, not a universal rule.
Use Apple’s review-request mechanism
Use StoreKit’s current review request action and let the system decide whether to display the standard prompt. Apple limits display to a maximum of three times within a 365-day period, and users can disable prompts. Calling the API does not guarantee the prompt appears.
Track the app-side eligibility and request call for QA, but do not claim that each call produced a visible prompt or review.
If the interface includes a user-initiated “Write a review” action, Apple documents a direct App Store URL with ?action=write-review. That is different from surprising the user with a custom rating gate.
The review-manipulation risk guide explains why purchased, exchanged, incentivized, or selectively routed reviews are not a shortcut.
Keep support easy to reach
Apple recommends making support contact information easy to find in the app and on the product page. Give dissatisfied users a real path to help without hiding the App Store rating option from them.
Useful support design includes:
- a visible in-app help or contact path;
- diagnostic context the user can choose to share;
- a response-time expectation the team can meet;
- a status page or known-issues note when appropriate;
- a way to recover from login, billing, sync, or data problems.
Support is not a negative-review filter. It is part of the product experience.
Build a review operations queue
Do not let reviews become an unowned inbox. Assign a response owner and a product owner for recurring themes.
Triage each review by:
| Dimension | Examples |
|---|---|
| Severity | data loss, payment failure, crash, confusion, request |
| Recency | current release, older version, unknown |
| Reproducibility | confirmed, needs details, cannot reproduce |
| Frequency | isolated, repeated, rapidly increasing |
| Market | country, language, pricing or localization context |
| Action | reply, investigate, fix, document, report concern |
Prioritize current technical failures and severe trust issues before polishing replies to generic praise. Apple specifically suggests prioritizing low-star reviews and technical issues when a team cannot answer everything.
Write a public response that helps
A strong reply is short, specific, respectful, and safe to publish.
Use this structure:
- Acknowledge the exact issue. Show that the review was read.
- State verified context. Mention a known fix or limitation only when accurate.
- Offer a practical next step. Point to support when account-specific details are needed.
- Close in the brand’s normal voice. Avoid pressure to change the rating.
Weak:
Sorry for the inconvenience! Please email support.
More useful:
Thanks for flagging the export failure after the latest update. Version 4.2.1 includes a fix for the PDF issue. If it still happens after updating, contact [email protected] with the device model so we can investigate without asking you to post private details here.
Do not include personal information, marketing copy, spam, blame, or sensitive troubleshooting. Do not argue about the star rating. If a review contains offensive material, spam, or other prohibited content, use App Store Connect’s Report a Concern option instead of escalating publicly.
Reply to praise without turning it into an ad
Positive reviews still teach you what customers value. A concise response can reinforce the feature or outcome they mentioned.
Example:
Glad the batch export is saving time—thanks for explaining how you use it.
Avoid pasting the same enthusiastic template under every review. Repetition looks automated and misses the learning in the customer’s words.
Close the loop after a fix
When a release resolves an issue mentioned in older reviews:
- verify the fix is live;
- explain it accurately in release notes when appropriate;
- reply to relevant reviews with the version and change;
- provide support for anyone still affected;
- monitor new reviews and product telemetry for recurrence.
Apple notes that replying can re-engage previously dissatisfied users because the reviewer is notified. Invite them to try the fixed path; do not demand or reward a rating change.
Mine reviews for product and ASO insights
Reviews are qualitative evidence, not a keyword list to copy blindly.
Create a small theme taxonomy:
- promise or audience mismatch;
- onboarding or permission friction;
- missing capability;
- usability or accessibility issue;
- crash, speed, login, sync, or data integrity;
- pricing, trial, subscription, or cancellation confusion;
- support experience;
- outcomes customers repeatedly value.
Count themes by period, version, rating range, and territory. Preserve representative examples internally, but avoid exposing private or sensitive content.
Competitor reviews can reveal category expectations and unresolved needs. Use repeated patterns, not one dramatic comment. Confirm that a requested feature fits your product before putting it in the roadmap or metadata.
For an ASO audit, review themes can answer:
- Does the listing attract people expecting another product?
- Which benefit do satisfied customers describe in their own language?
- Does a screenshot claim lead to disappointment after install?
- Is one localization generating a distinct complaint?
- Did a release resolve or create a visible issue?
Decide carefully before resetting the overview rating
Apple allows an overview-rating reset when releasing a new version. Written reviews remain. Apple advises using the option sparingly because fewer ratings can discourage downloads even when the new score better reflects the current app.
Consider a reset only after a material change and with an explicit trade-off:
- Was the prior rating driven by a problem the new version actually fixes?
- Can the team support and monitor the new release?
- Is losing accumulated rating volume worth the cleaner current-version signal?
- Will unresolved written reviews still create the same concern?
A reset is not a substitute for fixing the product or responding to customers.
Measure the review system without gaming it
Track:
- users eligible for the request trigger;
- request calls by app version;
- ratings and written-review volume by territory;
- rating distribution and recurring themes;
- response time and resolution status;
- crashes, support contacts, activation, retention, and refunds near problem periods;
- product releases, featuring, paid acquisition, and other source-mix changes.
Do not attribute every rating change to the prompt. New users, product changes, seasonality, support incidents, and country mix can move the same number.
The useful outcome is a healthier loop:
better product experience → appropriate request → honest feedback → useful response → prioritized product change
Final checklist
- The prompt follows a real value moment.
- Errors, support issues, cancellations, and interrupted tasks suppress the request.
- StoreKit controls the system prompt; there is no custom review gate.
- Support remains visible to every user.
- Reviews have a named response and product owner.
- Replies are specific, public-safe, and free of pressure.
- Repeated themes reach the backlog with frequency and severity.
- Fixed issues are communicated only after the fix is live.
- Territory and app-version context are preserved.
- No rating, review volume, rank, or conversion result is promised.