How to Ask for App Ratings and Reviews Without Breaking Store Rules

In short, the job has three parts: the right tool, the right moment and honest wording. In this guide, Talha Aslan and team walk through each part using official store documentation. Start with a quick check of your current app:

1. If your app shows a homemade "rate us" dialog, replace it with the official store prompt.
2. Offering discounts, coins or content for a rating? Remove that offer today.
3. If the prompt appears at launch, move it to the end of a successful task.
4. Negative reviews sitting unanswered? Build a reply plan that starts with the lowest ratings.

Why are the app stores so strict about ratings?

First, ratings are the most visible trust signal in any store. Before a person installs your app, they glance at the stars and the latest reviews. That is why Apple and Google protect the link between ratings and real experience so carefully.

Apple's App Store Review Guidelines warn developers who try to manipulate reviews with paid, incentivized, filtered or fake feedback. According to the guidelines, the consequences can go as far as removal from the Apple Developer Program. In addition, guideline 5.6.3 on discovery fraud says that manipulating any part of the store experience, reviews included, is not permitted.

Google takes the same line. The Google Play policy on user ratings, reviews and installs prohibits any manipulation of ratings, reviews or install counts. So on both stores, the real question is not "how do we collect more stars?" Instead, it is "how do we let genuinely happy users speak up?"

What is the official way to request app ratings on iOS?

The official route is Apple's StoreKit review request. Guideline 5.6.1 tells developers to use the provided API to prompt users for a review. The same guideline states that Apple will disallow custom review prompts. Therefore, drawing your own star screen and pushing users toward the store is a risky shortcut.

The system prompt lets users rate your app without leaving it. If they want, they can also write a short review in the same sheet. For years, the SKStoreReviewController class handled this job. However, Apple's current documentation marks that class as deprecated and points developers to RequestReviewAction and AppStore.requestReview instead.

On new projects, our team always follows the method that the current documentation recommends. Still, the class you call matters less than where and when you call it. For example, wiring the request to a button is a pattern Apple explicitly asks you to avoid. We cover that point in its own section below.

How does the Google Play In-App Review API work?

The Google Play In-App Review API is the official interface that lets users leave a rating and review without leaving your app. Your app starts the flow, and the Play Store then draws a card on top of your screen. Google always decides whether that card actually appears.

The Android developer documentation sets clear design rules for the card:

• Show the card as it is, without changing its size, opacity or shape.
• Do not add any overlay on top of the card or around it.
• Never close the card from code; the user or the Play Store removes it.
• Avoid asking the user any question before or while the card shows.

Also note that the API never tells you whether the user rated or how many stars they picked. That is a deliberate design choice. As a result, developers cannot treat users differently based on their rating. So never build logic that depends on the card having appeared.

How often can a review prompt appear?

Both stores cap how often one user sees the prompt. Apple's documentation says the system shows the request to a user a maximum of three times within a 365 day period. If the person already rated your app on that device, the prompt only returns for a new app version. Even then, more than 365 days must have passed since their previous review.

Google applies a time bound quota but does not publish the exact value. The documentation calls the value an implementation detail that Google can change without notice. It also warns that calling the flow more than once in a short period, for example less than a month, might not show a dialog.

In practice, this means you have very few chances. Therefore, save every request for your strongest moment. Apple also reminds developers that people can turn off review requests on their device entirely. In other words, the prompt is never guaranteed, so always check the current limits in the official documentation.

When is the best moment to ask for app ratings?

The best moment comes right after the user gets value from your app. Apple recommends asking when users are most likely to feel satisfied, such as after they complete an action, a level or a task. Google likewise wants users to have experienced enough of your app to give useful feedback.

In practice, that moment differs by product. The following example scenarios show trigger types our team often uses on client projects:

• Booking app: after the user completes a second booking without problems.
• Shopping app: when the user opens the app again after an order shows as delivered.
• Learning app: after the user finishes a module and closes the success screen.
• Game: after a hard level, during the natural pause before the next one starts.

The common thread is simple. The prompt follows a win, and it never lands in the middle of a task. One win may not be enough, though. That is why we usually wait for several positive signals together, for instance a minimum number of sessions and a crash free last session.

When should you never show a rating prompt?

Some moments can turn even your best user into an annoyed reviewer. Apple advises against showing the request right when the app launches, even if it is not the first launch. People open your app to do something, and your request should not block that goal.

Here are the moments our team avoids on every project:

• The middle of a checkout, a form or a sign up flow.
• A session where the app crashed, froze or lost its network connection.
• A day when the user contacted support or filed a complaint.
• Right after first launch and the onboarding screens.
• Any moment when the user follows a timer, a map or live content.

On the other hand, watch out for the idea of "never asking unhappy users." Systematically excluding dissatisfied people moves you close to the filtered feedback the guidelines mention. We base timing on the natural flow of the task, not on how happy the user seems. That way you follow the rules and still keep the experience calm.

Can you add a "Rate us" button to your app?

A button is fine, but tying it to the official prompt is not. Apple's documentation says that because the API may not present an alert, you should not call it in response to a button tap or other user action. Otherwise the user taps, nothing happens, and your app feels broken.

Google gives the same warning. A user might already have hit their quota, so Google advises against a call to action button that triggers the API. Instead, the documentation suggests sending the user straight to your Play Store listing.

The right setup therefore has two separate paths. First, the official prompt that opens on its own schedule after a win. Second, a plain link in settings or the about screen that opens your store page. For that second path, Apple's sample code appends an action parameter called write-review to the App Store product URL. This takes the user directly to the review composer.

Why do stores ban incentivized app ratings, and where is the line?

Rewarding users for reviews breaks the rules on both stores. Google's policy lists a notification offering a discount in exchange for a high rating as a direct example of a violation. Apple's guidelines likewise treat incentivized feedback as review manipulation.

Drawing the line correctly matters. Apple's guideline 3.2.2 forbids apps from forcing users to rate or review the app to access features or content. The same guideline lets apps incentivize other in app actions, such as completing a level or watching an ad. Put simply, a reward system is fine, but a reward tied to a rating is not.

Here is the distinction we use in practice:

• Allowed: a badge for completing a task, or a bonus after finishing a level.
• Not allowed: a "coupon for 5 stars" message or content that unlocks after rating.
• Not allowed: making a review a condition for using any feature.
• Avoid as well: nudging users to put coupon codes, email addresses or links to other apps inside reviews.

The last point often slips through. Google's policy counts encouraging promotional reviews of this kind as a violation too.

Can you ask "Do you enjoy our app?" before the prompt?

For Google Play, the answer is a clear no. The documentation says your app should not ask the user any questions before or while presenting the rating card. That includes opinion questions like "Do you like the app?" and predictive ones like "Would you rate this app 5 stars?"

The once popular pattern works like this: ask about satisfaction first, send happy users to the store and unhappy users to a feedback form. That is exactly why it causes trouble. It keeps negative opinions away from the store while it channels positive ones there. Consequently, it comes very close to filtered feedback.

On Apple's side, remember that custom review prompts are off limits as well. For that reason, we keep feedback collection and store rating requests completely apart. An in app "report a problem" or "send a suggestion" option stays open at all times. The store prompt, meanwhile, runs on its own schedule with no link to that form.

What are the key differences between iOS and Android rules?

The core principle is the same, but the details differ. The table below puts the points we verified in official documentation side by side:

Every value in this table comes from the stores' own documentation. However, stores update those pages over time. So check each row against the official source once more before release.

The practical takeaway is to build one logic layer for both platforms but two separate implementation layers. Keep trigger conditions, cooldowns and analytics events shared. Meanwhile, let the method you call, the test path and the store link follow each platform's own documentation. That keeps your codebase lean, and a rule change only touches one layer.

How do you build an app ratings flow step by step?

A solid flow starts on paper before anyone writes code. Here is the sequence our team follows when we add app ratings prompts to client projects:

1. Define your app's "value moment": when does the user finish their core task successfully?
2. Write eligibility rules, for example a few sessions and no errors in the last one.
3. Keep a local counter and record when you last triggered the prompt.
4. Set your own cooldown, and ask less often than the store quota allows.
5. Call the current StoreKit method on iOS and the In-App Review API on Android after the success screen.
6. Add a separate "rate this app" link in settings that opens your store page.
7. Log trigger events in your analytics tool and track them per version.

Step four deserves attention. The store quota protects you technically, but it does not protect the user experience. Your own rule should be gentler.

If you would rather not build this from scratch, we can design and develop your app and take it through store submission for you. Our mobile app development service plans store rules, including the review prompt, from day one; tell us about your project and request a quote.

How do you test the review prompt before release?

The two platforms behave differently during testing, so plan each one separately. According to Apple, StoreKit always displays the request while your app runs in development mode. That lets you check the interface and the flow freely. However, the same method has no effect in beta builds you distribute through TestFlight.

On Android, Google describes a few options. The quota does not apply when the app comes from the internal test track. For that, the account must be on the testers list, must have downloaded the app from the Play Store and must not have reviewed the app yet. With internal app sharing, on the other hand, users cannot submit reviews, and Google disables the button on purpose.

For unit and integration tests, there is also a FakeReviewManager class. It does not show any interface; it simply fakes a successful result for the flow. In other words, you confirm that the card really appears on the internal test track, not with this class. The in app review testing guide in the Android developer docs covers the setup details.

How should you respond to negative reviews?

Reply to a negative review briefly, respectfully and with specifics, because vague replies read as canned. Apple says the ideal response is concise and clearly addresses the customer's feedback. It should contain no personal information, marketing language or spam. If you cannot answer every review, Apple suggests prioritizing the lowest star ratings and reviews about technical issues in the current version.

On Google's side, the Play Console help page on ratings and reviews says you can post one public reply per review and edit it at any time. Users get both a push notification and an email when you reply. Moreover, they can change their rating or review whenever they like.

This is the reply pattern our team uses:

1. Acknowledge the problem in the user's own words.
2. Say clearly what you did, or which version contains the fix.
3. Point to your support channel if needed, but never ask for personal data.
4. Do not ask them to change their rating; show the fix and let them decide.

Google's reply guidelines also ask you not to solicit or promote anything in a response.

How do you recover after your app ratings drop?

Find the cause first, then ask for new ratings. Doing it in reverse just collects more low scores from the users who hit the problem. Play Console breaks ratings down by country, language, app version, Android version and device model. That breakdown often reveals that a single release or device group drives the drop.

Example scenario: after a release, an ordering app loses stars. The team checks the breakdown and sees the drop concentrated on one Android version. The cause is a crash on the payment screen. They ship a fix, reply to the complaints with the fixed version number and only then turn the prompt back on.

Also keep a remote switch that pauses the prompt. Then, during a crisis, you can turn it off without shipping a new build. Google notes that the displayed rating reflects your most recent ratings. Consequently, satisfied users who arrive after the fix lift the score over time. For other reasons people leave, see our guide on why users uninstall apps in the first seven days.

Should you reset your App Store summary rating?

Sometimes, but rarely. Apple's ratings and reviews page explains that the summary rating is specific to each App Store territory. You can reset it when you release a new version. That said, Apple recommends using this feature sparingly.

However, the reset has a clear limit. Apple states that resetting your summary rating does not reset your written reviews. So old complaints remain readable on your page. In addition, a fresh rating based on only a few scores may not inspire much confidence in new users.

We consider a reset in one situation. You fixed a major problem that dragged the old score down, and the new version is a substantial update. For a minor bug fix, a reset is usually unnecessary. Google Play does not describe a similar reset; its displayed rating already gives weight to recent ratings.

How do app ratings affect store visibility?

App ratings directly affect your store page conversion rate. In search results, people see the icon, the name and the stars together. That is why ratings sit at the heart of app store optimization. We covered the full topic in our guide to app store optimization, so we will not repeat it here.

Review text also matters. New users scan recent reviews for answers to their own worries: is delivery late, does payment work, does the app drain the battery? For that reason, fresh and specific reviews persuade almost as much as the average score.

App ratings alone are not enough, though. The visuals on your store page shape the first impression too. So pair your ratings work with our guide on app store screenshots that convert. If you want the bigger picture on how review volume influences buying decisions, our article on how product reviews affect sales helps as well.

How do you collect the first ratings for a new app?

With a new app, the problem is not a low score but no score at all. Because you have few users, every prompt opportunity carries more weight. So do not rush in the first weeks, and show the prompt only to users who truly got value.

Example scenario: a booking app has just launched. The team keeps the prompt off in the first release and watches crash and error rates. In the second release, once the flow is stable, they enable the prompt after a second successful booking. As a result, the first ratings come from users who saw the app at its healthiest.

On the other hand, asking friends and family for a wave of reviews may feel tempting. However, that path comes very close to what stores treat as fake or steered feedback. Instead, we suggest regular contact with early users, real product changes based on their input and patience while ratings arrive naturally.

Is it OK to ask for ratings by push, email or on your website?

Inviting people to your store page from outside the app is not banned in itself, but the same principles apply. Google's policy explicitly uses a notification that offers a discount for a high rating as a violation example. So the channel is not the issue; incentives and steering are.

Keep the invitation plain, for example: "If you would like to share your experience, you can use this link." Do not suggest a star count, do not promise a reward and do not send it only to a list of happy customers. Also keep these invitations rare, because frequent pushes are the fastest way to lose notification permission.

Which metrics should you track?

You cannot improve a prompt you do not measure, and app ratings are no exception. However, the store APIs never tell you whether a user rated. So you measure indirectly: you compare your own trigger events with the rating trend in the store console.

These are the core indicators we track:

• Number of sessions that triggered the prompt, by trigger type.
• Average rating and new rating volume per app version.
• Recurring themes in review text.
• Reply rate and reply time for negative reviews.
• Share of users who update their rating after a reply.

If you want to compare two triggers, you can split users into groups and measure the outcome. Our A/B test calculator then tells you whether the difference is significant. Even in a test, though, every group must see a prompt that follows store rules.

What are the most common mistakes?

When we join projects midway, we see the same mistakes again and again. The most frequent ones are these:

• A homemade star dialog that sends 5 star users to the store and everyone else to a form.
• Showing the prompt at first launch or right after onboarding.
• Wiring a "Rate us" button straight to the official prompt.
• Promising coupons, coins or bonus content in exchange for a rating.
• Leaving negative reviews unanswered or pasting the same canned reply everywhere.
• Asking users in a reply to raise their rating.
• Keeping the prompt active during a crisis release.

Some of these mistakes can cause trouble during store review. To understand that process, read our article on the most common app rejection reasons. If Google Play already removed your app over a policy issue, our Google Play appeal guide covers the first steps.

What should your pre-release checklist include?

Run through this short list before you submit a release. Ticking each item one by one prevents most problems later:

1. No custom star dialog exists besides the official prompt.
2. The prompt opens only after a success moment and respects your own cooldown.
3. No satisfaction question appears before or during the prompt.
4. No reward, coupon or lock relates to ratings or reviews.
5. Settings include a separate link to your store page.
6. A remote switch can disable the prompt.
7. Someone owns replies to negative reviews and follows a reply pattern.

The list looks short, yet each item reflects either a store rule or a lesson from real projects. That way you pass review smoothly and keep users comfortable.

Revisit the list with every major release. A new feature can quietly move the prompt to the wrong moment. For example, a new confirmation screen in checkout may break your old definition of the "success moment." For that reason, document your trigger definition in your product spec, not only in code.

What do you gain by working with a professional team?

A rating prompt looks like a few lines of code, yet product decisions, analytics and store policy sit behind it. Good timing requires knowing your app's value moment. Good measurement requires planning analytics events early. Compliance requires following two sets of store documentation that keep changing.

Talha Aslan and team design and build your app and handle its release on the App Store and Google Play. We set up the rating prompt, the review reply process and the store listing as part of that work. Visit our mobile app development page, tell us about your project and get a tailored quote.

In short, strong app ratings are the natural result of a strong experience. A compliant prompt simply carries that experience into the store, nothing more.