Ratings and Reviews Programme for iOS and Android

iOS gives you three review prompts per user per 365 days, and Android's In-App Review API will silently do nothing when its quota is spent, returning no error you can log. Every honest ratings programme is built inside those two facts. On a French holiday rental app the rating moved from 4.1 to 4.6 across five months and page-to-install conversion rose about nine percent in the same window. I would not tell you the rating caused all of it, because we shipped new screenshots in month three. Where the prompt goes: Timer-based prompts and prompts on app open are the two most common implementations and both are wrong. The prompt belongs immediately after an outcome the user chose and completed: a booking confirmed and returned to, a vet appointment saved, a second successful search. Choosing that moment is the engagement. I instrument candidate moments first, measure satisfaction proxies at each, then spend the three annual prompts on the two or three that survive. Prompting a user who has not yet had a good experience is not neutral: it converts a lukewarm user into a three-star rating that sits in your average for a year. What I refuse: Rating gates. Asking "are you enjoying the app?" and routing the unhappy answer to a support form instead of the store prompt breaks App Store Review guideline 5.6.1 and Play's developer policy, and I will not build one however many competitors in your category are running one today. Incentivised reviews, review vendors and internal review drives get the same answer. If you want those, we should not work together, and it is cheaper for both of us to establish that now. Replies are the other half: Store replies are read by the next prospect, not only by the reviewer. I build the triage taxonomy — bug, expectation mismatch, pricing, missing feature, wrong-app confusion — the reply policy per branch and the response SLA. Replies go out through the App Store Connect API and the Play Developer Reply API so the work lives in your tooling rather than a browser tab. A one-star review caused by a shipped bug gets a reply, and then a second reply when the fix lands. That second reply is the one that gets ratings changed, and almost nobody sends it. Ratings are per storefront: A 4.6 in France and a 3.9 in Germany are two different problems, and the German one is usually translation or a payment method rather than the product. I read the distribution by country and by app version before recommending anything. When the average is describing a release that no longer exists, I will say so and tell you that the iOS version reset is the honest tool for it. Yours to ship, not mine: Product fixes. You get the ranked list of what reviews say is broken; shipping it is yours. Replies in languages beyond English and French. Support desk operation. App Review appeals. Too small for this: Apps under roughly two thousand monthly active users, where prompt volume cannot move the average inside a quarter. Teams looking for a way to bury a rating that is accurate. Running order: Month one is instrumentation and the prompt decision, with the rating arithmetic done first so you know the realistic ceiling before anything is designed. Month two the prompts ship and replies start. From month three the cohort gets read monthly — rating by version, by country, by prompt moment — and the share of your three annual prompts is reallocated toward whichever moments prove out.