You add a rating prompt to an app in one call, and the store decides the rest.
To add a rating prompt to an app you call the store's own review API and let the operating system draw the dialog. On iOS that is StoreKit, on Android it is the Play In-App Review API, and in a React Native and Expo project one store review module covers both. The limit belongs at the top rather than the bottom of this page: you do not control whether the prompt appears. Apple's documentation says the system shows it to a person a maximum of three times in any 365 day period, Google enforces a quota whose value it does not publish, and anyone can switch review requests off for their whole device. Star counts still feed store ranking and the install decision, so this sits inside App Store Optimization rather than next to your other interface work.
This page covers the real caps, the guideline clauses that decide what you may put in front of the prompt, when to fire it so it is not wasted, and how to tell afterwards whether it did anything.
See where your three prompts goThe short version
Use the prompt the store gives you, and spend the few you get.
The build is small. Add the platform's review module, choose the moment, call it once, and do not look for a return value that tells you what happened, because there is not one. Everything else here is about the moment you choose, because you get very few of them.
The pattern that is gone is the funnel: a screen asking whether someone is enjoying the app, sending happy people to the store and unhappy ones to a feedback form. Apple disallows custom review prompts. Google forbids asking any question before or while the rating card is on screen. Build your feedback route separately and do not gate the store ask behind it.
Three a year, and you never learn which ones landed
Apple's documentation on requesting App Store reviews is direct about the ceiling. The system displays the review prompt to a person a maximum of three times within a 365 day period. The same page notes that people can disable requests for reviews from ever appearing on their device, and no code of yours can detect that or work around it.
The call gives nothing back either. There is no callback saying the dialog appeared, no result saying the person rated you, and no counter telling you how many of the three you have spent on this user. An in app review prompt is a request, not a command, and the code around it has to be written as though it may do nothing at all.
Google is vague on purpose. The Play In-App Review API documentation says Play enforces a time bound quota on how often a person can be shown the review dialog, that calling it more than once in a short period may display nothing, and that the specific value is an implementation detail which can change without notice. Asking twice inside a month is a coin flip.
One more surprise waits for anyone testing before release. The Expo store review module reports the feature as unavailable on iOS when the app is distributed through TestFlight, so a build handed to testers will not show the dialog. Newly ships iOS through TestFlight first, so you will not see the real card until the app is on the store. Verify the trigger with a log line, not with your eyes.
What the guidelines will not let you build
Three clauses of the App Store Review Guidelines govern this feature and they are short. Guideline 5.6.1, App Store Reviews, tells developers to use the provided API to prompt users to review the app, and says Apple will disallow custom review prompts. A star widget of your own design, however pretty, is the thing that clause exists to stop.
Guideline 3.2.2 lists what is unacceptable, and item ten says apps must not force users to rate the app, review the app, download other apps, or take other store related actions in order to access functionality, content, or use of the app. No coins for five stars, and no level locked behind a review. The introduction to section 3 goes further: manipulating reviews or inflating chart rankings with paid, incentivized, filtered or fake feedback can end in removal from the Apple Developer Program.
That is worth stating precisely, because the rule gets quoted loosely. Apple does not publish one tidy sentence saying never reward a review. It publishes a ban on forcing store actions in exchange for app functionality, a ban on custom prompts, and a policy of expelling developers who buy or manipulate feedback. Those three are the places to quote if you are writing policy for your own team.
Google's version reads as design guidance. Surface the card as it comes, with no overlay above or around it, no change to its size, shape or opacity, and no removing it yourself once it is up. The wider submission checklist is its own subject, and what the stores allow covers the parts that are not about ratings.
The moment is the whole design
Apple's best practice list runs to three lines. Ask at a time that does not interrupt what someone is trying to achieve, for example at the end of a sequence of events they completed successfully. Avoid showing a request the moment a person launches the app, even when it is not the first launch. Avoid requesting a review as the result of a user action.
That last line surprises people, and Google arrives at it from another direction. Google's documentation says you should not have a call to action such as a button that triggers the API, because someone who has already hit their quota will tap it and see nothing. If you want a Rate us row in a settings screen, point it at the store listing instead of the in app card.
Apple's sample code shows the shape of a sensible trigger. It waits until the person has finished the same three step task at least four times, and prompts only once per app version. Apple says the numbers are arbitrary. The principle is not: delay the ask until someone has enough of your app behind them to hold an opinion worth reading.
If the reason you want the prompt is traffic rather than feedback, the rating is one input among several, and how to get more app downloads covers the others.
Try it
Where your three prompts a year go
Pick the moment you were planning to ask, then set how often a year your code would fire the prompt at one person.
3 of 6 can be shown
Apple displays the system prompt at most three times per person in any 365 day period. 3 of those calls go nowhere, and your code never learns which ones. What both stores ask for. Ask at the end of something the person completed, once they have used enough of the app to judge it.
You can see the result, but not the cause
Neither API tells you what happened, so measurement is indirect. Log the moment your code fires the request, with the trigger that caused it and the app version, then line those dates up against the rating count and average in each store console.
Two numbers matter together: how many people reach your chosen trigger at all, and how many new ratings arrive per thousand who reach it. When the first number is small the prompt is not the problem, the path in front of it is. That instrumentation is ordinary mobile app analytics work, and it is far easier to add before a release than after one.
Expect the effect to be slow and lumpy. Reviews post on their own schedule, the yearly cap spreads your asks out, and a release that changes the trigger takes weeks to show. Judge a change here over a quarter rather than a week.
What each way of asking actually does
| Approach | Allowed by the rules | Shows every time you call it | Leaves the app | What you have to build |
|---|---|---|---|---|
| System prompt after a finished task | Yes | three a year at most | No | one call and a trigger |
| System prompt on every launch | against Apple's guidance | same yearly cap | No | one call |
| A Rate us button wired to the API | Google advises against it | No | No | a button that can do nothing |
| A link to the store listing | Yes | Yes | Yes | a URL and your app ID |
| Your own star popup | No | Yes | No | a rejection risk |
Building the prompt into an app you own
This is a small feature with a large amount of rule attached, which is the usual reason people get it wrong. The code is a dependency and one call. The work is deciding which moment in your app has earned the ask, and keeping the counters that hold that decision. That is product work, not plumbing.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own, runs it on a cloud simulator while it builds, and ships it to TestFlight and to Google Play internal testing. It costs $25 a month and there is no free plan. Because the source is yours, wiring a store review module to your own trigger is an edit you make rather than a feature you wait for.
Before writing any of it, settle what the prompt is for. If you want feedback, build a route to it that has nothing to do with the store. If you want the average up, fix the reason people would give you three stars first. The prompt is an amplifier, and it amplifies whatever is already true.
Questions people ask about rating prompts
Apple's documentation says the system displays the review prompt to a person a maximum of three times within a 365 day period, whatever your code does. Google Play enforces a quota as well, but says the value is an implementation detail that can change without notice. Plan for roughly one useful ask per person per release cycle.
Describe the moment worth asking at
Write down the one thing a person finishes in your app that would make them glad you asked, then build the app around that moment.
Start building