How to Get More App Reviews (Without Breaking the Rules)

Your star rating is the most consequential number on your store listing, and it is set almost entirely by users you never deliberately asked.

The stakes are steeper than most founders realize. Apps below 4.0 stars see up to 70% lower conversion than apps at 4.5 and above, and roughly 4.4 is the practical floor for competing in a category on either store. The gap between 4.0 and 4.5 is worth more than the gap between 4.5 and 4.8, which means the whole game is getting off the bottom rung, not chasing perfection.

Here is how to earn reviews honestly, when to ask, and what the platforms will punish you for.

Why ratings compound

A rating is not just a number on your listing. It works three ways at once:

Conversion. Someone who searched, found you, and is deciding between three options uses the star rating as the fastest available proxy for quality. A 4.7-star app converts roughly 15 to 25% better than a 4.0-star one from the same impression.

Ranking. Both stores factor rating volume and recency into where you appear. A stale pile of old reviews carries less weight than a steady trickle of recent ones, which is why review generation is a habit rather than a launch task.

Compounding early. A handful of one-star reviews on a 20-review app craters the average, and that average then suppresses every future install, which suppresses the reviews that would fix it. Early ratings are unusually expensive mistakes, which is the real argument for beta testing before you launch.

The one rule of timing

Ask immediately after a moment of success, and never at any other time.

Good moments: the user finished their first real session, hit a milestone, completed a streak, got the result they installed for, or resolved a support issue happily. In that window they feel good about your product and the ask reads as natural.

Bad moments, all of which reliably generate one-star reviews: during onboarding before value has landed, in the middle of a task, right after a crash or an error, immediately after showing the paywall, or on a fixed timer that ignores what the user is doing. A prompt after a crash is not a request, it is an invitation to vent.

This is the same timing principle behind permission requests and referral asks, and it is worth stating plainly: ask for things right after you have given something. If you only take one thing from this article, take that.

What the platforms actually allow

The rules are stricter than founders assume, and violating them is an account-level risk, not a slap on the wrist.

Use the native prompt. On iOS, Apple's in-app review controller is the only permitted in-app review prompt. You cannot build your own rating dialog, and you cannot route users to a custom form that decides who gets sent to the store.

Respect the display cap. The native iOS prompt can be shown at most three times per user per 365 days, and the system may suppress it further. You get roughly three shots a year per user, which is a strong argument for spending them at your best moment rather than sprinkling them around.

Never gate by sentiment. The old trick of asking "do you like the app?" and sending only the happy users to the store is prohibited on both platforms. It is also detectable, and it corrupts the signal your rating is supposed to carry.

Never buy or incentivize positive ratings. You may offer a modest incentive for leaving an honest review, in-app currency, an achievement, early access. You may not condition any reward on the rating being positive or five stars. Both stores prohibit rewards tied to rating value, and purchased reviews are an enforcement target with penalties up to removal.

The distinction that matters: incentivizing the act of reviewing is allowed in limited forms, incentivizing the content is not.

Tactics that work inside the rules

Fix the unhappy path before it reaches the store. This is the single highest-return move, and it is fully legitimate as long as you are not gating the prompt. Give users an obvious, easy way to reach you when something goes wrong: a visible support link, a fast reply, a real human. Users who feel heard often do not write the angry review at all, and some become your best reviewers later. You are not intercepting reviews, you are resolving problems.

Ask sparingly and specifically. One well-placed prompt per genuine milestone beats a prompt on every third launch. Given the three-per-year cap, treat each as a scarce resource.

Ask your known-happy users directly. Beta testers, waitlist members, people who emailed you compliments, and anyone who has used the app for months. A short personal note asking for an honest review converts far better than any in-app prompt, and these are exactly the users whose reviews will be detailed and credible.

Respond to every review, especially the bad ones. Both stores let you reply publicly. Future browsers read the responses, and a calm, specific, non-defensive reply ("this was a bug in 1.2, fixed in 1.3, sorry about that") does more for a prospective user than the complaint does against you. Users sometimes update their rating after a good response, and asking politely for that update is allowed.

Ask again after you fix something. When you ship the fix a reviewer asked for, tell them. That is the highest-conversion moment for a rating update that exists.

Read the reviews as product input

Beyond the number, reviews are the cheapest continuous research you will ever get, and unlike surveys they are unprompted.

Read all of them, weekly. Tag them the way you would tag beta feedback: bug, confusion, missing feature, pricing objection. Then watch for repetition, because three people describing the same confusion is a design problem, and one person's strong preference is a preference.

Two patterns to watch for specifically. A cluster of one-stars appearing right after a release means you shipped a regression, and that is an emergency, not a rating problem. A steady drip of "I didn't understand how to..." means your onboarding is leaking, and fixing it will move retention and rating together.

A realistic plan

If you are launching or recently launched:

1. Do not prompt anyone during onboarding. Ever. 2. Pick one milestone that reliably means "this worked for you" and put the native prompt there. 3. Put a visible support path in the app, and answer it fast. 4. Personally ask your beta testers and earliest users for honest reviews in the first weeks, when volume matters most. 5. Reply to every review, and follow up with the negative ones when you ship the fix. 6. Read and tag reviews weekly as product input.

None of this is clever. The clever tactics, sentiment gating, bought reviews, five-star incentives, are precisely the ones that get apps removed, and they are trying to fake a signal you can earn instead. A rating above 4.4 is mostly the visible byproduct of an app that works and a founder who answers their support email.