Ask for the app rating right after something went right

The worst moments to ask

Open almost any app for the third time and you'll see it. A little box asks how many stars you'd give. Sometimes it appears the second the app launches, before you've done anything. Sometimes it interrupts a checkout. And sometimes it shows up right after the payment failed, which is the one moment you're guaranteed an honest answer.

The prompt is the same either way. The moment is what you're choosing. Most teams pick it by accident: someone adds the call on app launch, behind a counter, and it fires whenever the counter says so.

This note is short because the fix is short. Choose the moment on purpose.

It matters more than it looks. Ratings sit right under your app's name in the store, and they're one of the first things a new customer sees before deciding whether to install. Reviews written in frustration also tend to be about the moment, not the product, so they tell you less than you'd hope.

What the platforms actually allow

Both stores limit how often their system prompt can appear, so you can't make up for a bad moment by asking more often.

On iOS, Apple's documentation says that if the person hasn't rated or reviewed your app on that device, StoreKit shows the request at most three times in a 365-day period. Your code can ask more often. The system simply won't show it. Apple also says not to call the review request from a button tap, because the prompt might not appear and the button would look broken.

On Android, Google's guide for the Play In-App Review API says to trigger the flow after the user has used the app enough to give useful feedback, not to prompt excessively, and that quotas apply. It also says your app shouldn't ask any questions before or while showing the rating card. That includes "Do you like the app?" Google also says not to put the API behind a call-to-action button. If you want a "Rate us" button, send it to the Play Store page instead.

Put together, you get perhaps three good shots a year per person on iOS, and an unpublished quota on Android. Spend them well.

Pick the win

A good moment has three things in common. The user just finished something. It worked. And they aren't in the middle of the next thing.

Some examples, depending on the app:

• The order they placed last week was delivered, and they opened the app to see it.
• The appointment was confirmed, and they're looking at the confirmation screen.
• They got through a task for the third time without contacting support.
• A support ticket was marked solved, and they've used the app normally since.

Notice what's missing from that list. Nothing about time since install, number of launches, or days active. Those numbers are easy to count, which is why most apps use them, but they say nothing about whether the last few minutes went well. A user who opened the app ten times because something kept failing has a high launch count and a bad week.

Write down two or three moments like these for your app, in plain language, and have product agree on them. That list is the feature. The code is easy.

Never right after a bad moment

The opposite list matters just as much. Suppress the prompt after an error message, a crash, a failed payment, a timeout, a sign-in problem or any contact with support in the last few days. Also suppress it the first time someone opens the app after an update, because they're probably still finding out what moved.

This is where most apps go wrong. The counter doesn't know what just happened, so it fires anyway. If your app already sends notifications by priority, you already have the right habit: decide by context, not by count.

Leave a door open, and don't gate it

Some people want to leave a review on their own schedule. Apple explicitly allows a persistent link to your App Store page in settings, and on Android a "Rate us" button should go to the Play Store listing. Put that link where people look for help and settings, and leave it there.

Don't add a pre-question that sends happy users to the store and unhappy users to a feedback form. Google's guide rules out asking about their opinion before the card. It also makes your ratings less honest, which is the thing you were trying to learn from.

If you want to hear from unhappy users, and you should, give them an easy "Something wrong?" path in the app that reaches a person. Just keep it separate from the rating prompt.

And read the reviews you do get. Answer the specific ones, especially the unhappy ones, from a person on the team. Both stores let developers reply publicly. A calm, useful reply to a one-star review is often read by more future customers than the review itself.

Put this into practice

Find where your app calls the review prompt today. It's usually one line. Note what triggers it.

Then replace the trigger with your list of wins, add the suppression list, and log each time you ask and what moment triggered it. Add the permanent link in settings. After a month, look at whether reviews mention the things your best moments are about.

If you run both iOS and Android, keep the same list of moments on both, even though the platforms limit the prompt differently. Your users don't care which store they're in, and one shared rule is easier to test and explain. Write the moments and suppressions somewhere the whole team can find them, so the next person who touches the code doesn't move the prompt back to app launch.

This kind of small, decisive product change is a big part of mobile application development work, and it's one we enjoy. If your rating prompt fires on launch, talk to us.

Related work: PatientIQ.