Few or Poor App Reviews? Prompt, Reply and Rebuild Ratings
Review velocity is how quickly new ratings and reviews arrive. When it is low, your star rating rests on old opinions, a handful of unhappy users can drag it down, and the listing looks quiet next to competitors. When the rating itself is poor, fewer people install.
Both problems usually come from the same places: the app never asks for a rating, asks at the wrong moment, or ships issues nobody fixes or answers. This guide covers the official prompts on iOS and Android, when to trigger them, how to reply to reviews, and how to recover after a bad release.
Why velocity matters as much as the average
A 4.6 built from years-old reviews looks less convincing than a 4.4 with dozens of recent ones, and it is more fragile. If an app gathers only a few ratings a month, three angry reviews after one bad update can move the average noticeably. Steady velocity smooths that out.
The stores also treat recent opinion as more important than old opinion. Google has said that the rating shown on Google Play gives more weight to recent ratings, so an app that improves can see that reflected, and one that declines cannot hide behind its history. On iOS you can choose to reset the summary rating when you release a new version, which is useful after a major improvement but only makes sense if you can then gather new ratings quickly.
There is a difference between ratings and reviews. A rating is a tap on the stars; a review adds a title and text. The official prompts on both platforms let people rate with minimal effort and optionally write a review. Ratings feed the average; written reviews are what visitors read and what tells you what to fix.
The rules on both stores
Both stores are strict about how you ask. Breaking these rules can get an update rejected or the app removed, and it is not worth the risk.
| Rule | Apple App Store | Google Play |
|---|---|---|
| How to ask inside the app | Use the system review prompt from StoreKit. Custom pop-ups that ask for a rating are not allowed. | Use the In-App Review API from the Play libraries, which shows Google's own rating card inside the app. |
| How often it appears | The system limits how often a user sees the prompt, whatever your code requests. | Google applies a quota and does not publish the exact number, so a call may show nothing. |
| Filtering | Do not ask only the users you expect to be happy. | Do not ask questions before the prompt, such as "Do you like the app?", to decide who sees it. |
| Incentives | No rewards, in-app currency or unlocks in exchange for ratings. | No incentives; rewarding reviews breaks Google's policies. |
| Fake reviews | Manipulating ratings, including paid or fake reviews, can lead to removal from the developer programme. | Manipulated ratings are a policy breach and can lead to enforcement against the app or the account. |
The fix, step by step
Step 1
Read and tag your recent reviews
Export or read the last few months of reviews from App Store Connect and the Play Console, and give each one a short tag such as crash, login, price, missing feature, confusing or listing mismatch. Count the tags for one-star and two-star reviews separately. A tally like this turns a wall of complaints into a ranked list of problems and shows whether low ratings share one cause or several different ones.
Step 2
Fix what the low ratings describe
Before asking more people for ratings, fix the top one or two complaints from your tally, because prompting users who are hitting a known crash only adds more poor ratings. Check crash and freeze reports in Xcode Organizer and in Android vitals in the Play Console, since stability problems often sit behind vague reviews. If the complaint is that the app is not what the listing promised, change the listing wording or screenshots, not only the app.
Step 3
Choose a moment of real success
Pick one or two points where a user has just got value from the app: finishing a workout, sending a first invoice, completing a level or saving a document. Add simple conditions, such as the user having opened the app on several separate days and not having seen an error in this session. Never ask on first launch, in the middle of a task, straight after a purchase fails or while the user is trying to leave a screen.
Step 4
Add the official iOS prompt
In
SwiftUI, read the requestReview action from the environment and call it at the moment you
chose; in UIKit, call the StoreKit request method with the current window scene. The system decides whether
the prompt actually appears and limits how often each user sees it, so treat the call as a request. It
always appears while developing in Xcode and never through TestFlight, so check the logic with debug
logging rather than by counting prompts.
Step 5
Add the Google Play In-App Review flow
Add the Play review library, create a ReviewManager, call requestReviewFlow()
ahead of time and, at your chosen moment, pass the result to launchReviewFlow(). Carry on
with the app when the flow completes, because you cannot tell whether a card was shown or a rating given.
Do not trigger it from a "Rate us" button. Test with internal app sharing or an internal testing track,
and use FakeReviewManager in automated tests.
Step 6
Reply to reviews every week
Set a fixed weekly slot to answer new reviews in App Store Connect and the Play Console, starting with the lowest ratings and the most helpful complaints. Thank the person, answer the specific point, say what you are doing about it and give a support route if they need help. When a fix ships, update your reply to say so, because reviewers may be notified and some revise their rating.
Step 7
Track velocity by version
Record the number of new ratings per week and the average rating for each app version in a spreadsheet, alongside the date the prompt logic changed. If velocity rises but the new ratings are lower than before, your prompt moment is catching people at a bad time, so move it. If velocity barely moves, the conditions may be too strict and too few users ever reach the prompt, so loosen them slightly and measure again.
Minimal code for each platform
iOS with SwiftUI
import StoreKit
import SwiftUI
struct ExportDoneView: View {
@Environment(\.requestReview) private var requestReview
let exportsCompleted: Int
var body: some View {
Text("Your report is ready")
.task {
// Ask only after several successful exports
if exportsCompleted >= 3 {
try? await Task.sleep(for: .seconds(1))
requestReview()
}
}
}
}Waiting a moment lets the user see their success before the system card appears. Keep your own record of when you last requested a review so you do not call it on every visit to the screen.
Android with Kotlin
val manager = ReviewManagerFactory.create(context)
fun maybeAskForReview(activity: Activity) {
manager.requestReviewFlow().addOnCompleteListener { request ->
if (request.isSuccessful) {
manager.launchReviewFlow(activity, request.result)
.addOnCompleteListener {
// Continue normally: you cannot tell if a rating was left
}
}
}
}Check the current library names and versions in Google's Android developer documentation before adding the dependency, because the Play libraries have been reorganised over time.
action=write-review
parameter; on Android, open your Play listing. Unlike the prompt, this only appears when the user chooses
it.Writing replies that help
Replies are public. Future visitors read them to judge how you treat customers, so a calm, specific answer to a harsh review can do more for conversion than the review did harm.
- Be specific. "Sorry the export to PDF failed on the iPad. We found the cause and the fix is in version 3.2, out this week" beats "Thanks for your feedback, we are always improving."
- Do not argue. Even if the reviewer is wrong, correct the facts politely and briefly.
- Move private matters out. For billing, account or personal data issues, point to your support page or email address rather than discussing details in public. Never ask for passwords or payment details.
- Reply to good reviews sometimes. A short thank-you shows the app is looked after, but prioritise the reviews where a reply changes something.
- Use templates as a starting point only. Copy-pasted replies are obvious to readers and suggest nobody read the review.
Both stores let you report reviews that break their rules, such as spam, offensive content or reviews for the wrong app. Use that option for genuine breaches only; a negative but honest review is not a breach.
Recovering after a bad release
When a release causes a wave of one-star reviews, act in this order:
- Stop the damage. On Google Play, halt a staged rollout if the release is still rolling out. On iOS, pause a phased release if you used one. Ship a fix as quickly as review allows.
- Answer the wave. Reply to the affected reviews with the same honest message: what went wrong, that a fix is coming and how to get help now.
- Update the replies when fixed. Change each reply to say which version contains the fix.
- Hold the prompt. Do not trigger review prompts until the fix is out and users have had a good session on it.
- Consider a rating reset on iOS. If the new version is a real improvement, you can choose to reset the summary rating when releasing it. Written reviews remain on the page, and the rating starts from new ratings only, so only do this when your prompts can rebuild it.
A worked example
Pebblecast, a fictional podcast app, shipped an update that logged some users out. One-star reviews arrived within hours. The team halted the Play rollout, paused the iOS phased release, replied to each review with the same short explanation and a support link, and shipped a fix. Once the fix was live they edited every reply to name the fixed version, and turned the review prompt back on only for users who had completed an episode on the new version.
1. How many times can I show the App Store review prompt?
Apple limits how often the system review prompt is shown to each user, and your code cannot override that. Calling the request method is therefore a request, not a command. Apple documents the current limit in its StoreKit documentation, so check there rather than relying on figures quoted in older articles. Because of the limit, spend each chance carefully: ask after a clear moment of success, never on first launch and never in the middle of a task.
2. Why is the Google Play In-App Review card not appearing?
Google applies a quota to how often the card can be shown and does not publish it, so repeated calls during testing often show nothing. It also only works when the app was installed from Google Play, so sideloaded builds will not show it. Test using internal app sharing or an internal testing track with an account that has not already reviewed the app, and use FakeReviewManager in automated tests to check your logic without depending on the real card.
3. Can I ask users if they like the app before showing the review prompt?
Not for the purpose of deciding who sees the prompt. Google's In-App Review guidelines say not to ask questions about the user's opinion before or while showing the card, and Apple requires its own system prompt rather than custom rating pop-ups, which rules out gating it behind a question. You can collect feedback in the app for your own use, but it should not decide who is asked to rate. Instead, rely on neutral conditions such as repeated use and a completed task.
4. Should I reply to every negative review?
Reply to as many as you can, prioritising those that describe a real problem, mention something you have fixed, or are likely to be read because they are recent and detailed. Visitors notice when complaints go unanswered. Keep replies short, specific and polite, and move account or billing matters to a private support channel. For abusive or spam reviews, report them through the store rather than responding in public, and do not argue with honest criticism.
5. Should I reset my App Store rating with a new version?
Only when the new version is a genuine improvement and you are confident you can collect new ratings quickly. Resetting clears the displayed summary rating, so the listing may show few or no ratings until new ones arrive, which can itself put visitors off. Written reviews remain visible. For an app with steady review velocity and a much better release, a reset can help; for a quiet app, it may leave the listing looking empty for weeks.
6. Can I offer a reward for leaving a review?
No. Both stores prohibit rewarding users for ratings or reviews, whether with money, discounts, in-app currency, extra features or entry into a prize draw. Doing so can get updates rejected, reviews removed and, in serious cases, the app or developer account suspended. You can reward users for other actions if you wish, but never tie a reward to leaving a rating. Improving the moment you ask is the reliable way to increase velocity.
7. Why is my Google Play rating different from what I see in the console?
The rating shown on Google Play is calculated by Google and gives more weight to recent ratings, and the store can show ratings tailored to the viewer's country and device type. The Play Console lets you view ratings in several ways, including over time and by country, so the figure you pick there may not match what a particular visitor sees. Compare like with like by filtering the console to the country and device you are checking.
The App Store Audit checks your iOS and Google Play listings for keyword visibility, screenshot effectiveness, review velocity and rating, and conversion from impression to install, and benchmarks you against direct competitors.
Open App Store Audit Fixes →