Ratings Mechanics
The rating is an asset with mechanics most developers learn the hard way. This skill covers the
four rules that aren't obvious from the ASC UI. Prompting code lives in
generators/review-prompt; reply writing lives in app-store/review-response-writer — this
skill is the strategy layer that tells you when each matters.
When This Skill Activates
- Localizing or expanding into new storefronts ("why does my app show no rating in Japan?")
- Considering the "reset ratings summary" option on a version release
- Choosing release options before submitting (phased vs immediate, auto vs manual)
- Planning a per-market ratings strategy alongside
product/localization-strategy
- A bad build or review-bomb is threatening the rating
Rule 1: Ratings are per-storefront — they do not travel
Your 4.8★ from 2,000 US ratings renders as no rating at all on the Japanese storefront until
Japanese users rate the app there. Every storefront starts from zero.
Consequences:
- ✅ Entering a new market = re-running the early-days ratings playbook in that market: prompt
eagerly (within guidelines), localize the prompt moment, reply to every early review.
- ✅ Weight
requestReview triggers by storefront maturity — a market with 12 ratings needs the
prompt more than the home market with 5,000.
- ❌ Assuming social proof transfers with the binary. A localized listing with zero local ratings
converts like an unknown app, because there it is one.
- The written-review pool is also per-storefront: expect empty review sections in fresh markets
and seed them via TestFlight communities or launch outreach in that region.
Rule 2: Never reset the ratings summary
ASC offers a reset when you release a new version. It is almost always a mistake:
- Reset discards the count as well as the average — 4.2★ from 3,000 ratings converts better than
a naked 5.0★ from 6, and the count never comes back except one rating at a time.
- The instinct to reset ("v2 is a big rewrite, old reviews don't apply") is better served by
replying to outdated negative reviews (updated ratings replace the old score — see
review-response-writer) and by the What's New copy.
- ✅ Legitimate near-exception: a catastrophic launch (sub-3★, low count, fixed root cause) on an
app with almost no ratings mass. Even then, run the math on count loss first.
- ❌ Resetting an established app to chase a higher average. You'll rank and convert worse for
months.
Rule 3: Phased release + manual release are rating armor
Two ASC toggles turn a bad build from a rating catastrophe into a contained incident:
- Manual version release — approval ≠ release. Release when you're awake and watching
crash dashboards, not whenever review finishes.
- Phased release — 7-day staged rollout (1% → 2% → 5% → 10% → 20% → 50% → 100%) to users
with automatic updates. A crashing build caught on day 1–2 has burned ~3% of your users;
pause the rollout, fix, resubmit. Without it, 100% of users get the bad build and the
1-star flood arrives before the hotfix does.
- ✅ Default for every release: phased ON + manual release + monitor day-1 crash rate.
- ❌ Halting a phased release as a rollback. Pausing stops new deliveries only — users who got
the build keep it, and manual App Store downloads always get the new version. The armor is
damage limitation; the fix still has to ship.
Rule 4: The prompt-and-reply loop is the only rating input you control
- Prompt at success moments with
requestReview — never at launch, never mid-task. Aim the
moment, cap the frequency, and localize what "success" means per market. Implementation:
generators/review-prompt.
- Reply to negative reviews — when a user updates their review after a reply, the new score
replaces the old one in the average. Replies are the only mechanism that converts existing
1-stars into 4-stars. Templates:
app-store/review-response-writer.
- Per-storefront corollary: track "unanswered negative reviews" per market, not globally — a
5-review storefront is one bad review away from 60% negative.
Output Format
When auditing an app's ratings posture, report per storefront:
Storefront | Rating (count) | Unanswered 1–3★ (90d) | Prompt localized? | Phased+manual habit?
flagging: fresh storefronts with no prompting plan, any reset consideration (🔴 stop), and
releases going out unphased.
References
1---2name: ratings-mechanics3description: How App Store ratings actually behave — per-storefront isolation (your US stars show nowhere else), the never-reset rule, phased release + manual release as rating protection, and where prompting/replying fit. Use when planning ratings strategy for new markets, considering a ratings reset, setting release options, or diagnosing "why is my rating missing in country X."4---5
6# Ratings Mechanics
7
8The rating is an asset with mechanics most developers learn the hard way. This skill covers the
9four rules that aren't obvious from the ASC UI. Prompting *code* lives in
10`generators/review-prompt`; reply *writing* lives in `app-store/review-response-writer` — this
11skill is the strategy layer that tells you when each matters.
12
13## When This Skill Activates
14
15- Localizing or expanding into new storefronts ("why does my app show no rating in Japan?")
16- Considering the "reset ratings summary" option on a version release
17- Choosing release options before submitting (phased vs immediate, auto vs manual)
18- Planning a per-market ratings strategy alongside `product/localization-strategy`
19- A bad build or review-bomb is threatening the rating
20
21## Rule 1: Ratings are per-storefront — they do not travel
22
23Your 4.8★ from 2,000 US ratings renders as **no rating at all** on the Japanese storefront until
24Japanese users rate the app there. Every storefront starts from zero.
25
26Consequences:
27
28- ✅ Entering a new market = re-running the early-days ratings playbook *in that market*: prompt
29 eagerly (within guidelines), localize the prompt moment, reply to every early review.
30- ✅ Weight `requestReview` triggers by storefront maturity — a market with 12 ratings needs the
31 prompt more than the home market with 5,000.
32- ❌ Assuming social proof transfers with the binary. A localized listing with zero local ratings
33 converts like an unknown app, because there it *is* one.
34- The written-review pool is also per-storefront: expect empty review sections in fresh markets
35 and seed them via TestFlight communities or launch outreach in that region.
36
37## Rule 2: Never reset the ratings summary
38
39ASC offers a reset when you release a new version. It is almost always a mistake:
40
41- Reset discards the count as well as the average — 4.2★ from 3,000 ratings converts better than
42 a naked 5.0★ from 6, and the count never comes back except one rating at a time.
43- The instinct to reset ("v2 is a big rewrite, old reviews don't apply") is better served by
44 replying to outdated negative reviews (updated ratings **replace** the old score — see
45 `review-response-writer`) and by the What's New copy.
46- ✅ Legitimate near-exception: a catastrophic launch (sub-3★, low count, fixed root cause) on an
47 app with almost no ratings mass. Even then, run the math on count loss first.
48- ❌ Resetting an established app to chase a higher average. You'll rank and convert worse for
49 months.
50
51## Rule 3: Phased release + manual release are rating armor
52
53Two ASC toggles turn a bad build from a rating catastrophe into a contained incident:
54
55- **Manual version release** — approval ≠ release. Release when you're awake and watching
56 crash dashboards, not whenever review finishes.
57- **Phased release** — 7-day staged rollout (1% → 2% → 5% → 10% → 20% → 50% → 100%) to users
58 with automatic updates. A crashing build caught on day 1–2 has burned ~3% of your users;
59 **pause** the rollout, fix, resubmit. Without it, 100% of users get the bad build and the
60 1-star flood arrives before the hotfix does.
61- ✅ Default for every release: phased ON + manual release + monitor day-1 crash rate.
62- ❌ Halting a phased release as a rollback. Pausing stops *new* deliveries only — users who got
63 the build keep it, and manual App Store downloads always get the new version. The armor is
64 damage *limitation*; the fix still has to ship.
65
66## Rule 4: The prompt-and-reply loop is the only rating input you control
67
68- **Prompt** at success moments with `requestReview` — never at launch, never mid-task. Aim the
69 moment, cap the frequency, and localize what "success" means per market. Implementation:
70 `generators/review-prompt`.
71- **Reply** to negative reviews — when a user updates their review after a reply, the new score
72 replaces the old one in the average. Replies are the only mechanism that converts existing
73 1-stars into 4-stars. Templates: `app-store/review-response-writer`.
74- Per-storefront corollary: track "unanswered negative reviews" per market, not globally — a
75 5-review storefront is one bad review away from 60% negative.
76
77## Output Format
78
79When auditing an app's ratings posture, report per storefront:
80
81```
82Storefront | Rating (count) | Unanswered 1–3★ (90d) | Prompt localized? | Phased+manual habit?
83```
84
85flagging: fresh storefronts with no prompting plan, any reset consideration (🔴 stop), and
86releases going out unphased.
87
88## References
89
90- https://developer.apple.com/documentation/storekit/requesting-app-store-reviews
91- https://developer.apple.com/help/app-store-connect/update-your-app/release-a-version-update-in-phases
92- https://developer.apple.com/help/app-store-connect/monitor-app-performance/reset-your-app-s-summary-rating
93- Related skills: `generators/review-prompt`, `app-store/review-response-writer`, `product/localization-strategy`, `growth/store-growth-audit`
rshankras