CRT/storebound
1
0
Fork 0
Code Issues Pull requests Releases 1 Packages 1 Activity Actions
storebound/skills/review-rejections/SKILL.md

5.7 KiB
Raw Blame History

name description
review-rejections Triage and answer an App Store or Google Play rejection, policy warning or strike for a mobile app or game - decide fix / clarify / push back / appeal, write a short Resolution Center reply, and map the message to the usual guidelines (Apple 2.1, 2.3, 3.1.1, 4.2, 4.3, 5.1.1, 5.1.2, privacy label mismatch; Play Data safety mismatch, disruptive ads, Families, strikes and appeals). Use when the user pastes a rejection or policy email, an update is "Rejected" / "Metadata Rejected", or Play Console shows a policy issue.

Review rejections and policy issues

Read the full message first (App Store Connect > the app > App Review > the submission; Play Console > Policy status / Inbox). Quote the guideline number and the reviewer's exact sentence back to the owner before proposing anything. Never suggest hiding behaviour from reviewers, different builds for review, fake accounts or other manipulative tactics: they turn a rejection into an account termination.

1. Triage (pick one, say why)

route when what you do
Fix the reviewer is right (crash, missing restore button, wrong label) change the app / metadata, resubmit, reply what changed
Clarify the feature exists but the reviewer did not find it, or misread it reply with exact steps / a video link; no new build if nothing changed
Push back the guideline does not apply, with a concrete reason short factual reply quoting the guideline text; offer a call
Appeal a clarification was rejected and you still believe it complies Apple: App Review Board appeal form; Play: the appeal form linked from the notice

Start with Fix or Clarify; Push back only with evidence; Appeal last. Always ask the owner before sending anything.

2. Reply template (Resolution Center / appeal, under 200 words)

Hello, thank you for the review.

Regarding Guideline <n> (<reviewer's point in one line>):
<What we changed in build <number>> | <Where the feature is: Home > Settings > Restore Purchases>
<One sentence of evidence: screenshot / video link, or the guideline sentence that applies>

<If a new build:> Build <number> is attached to this submission.
Happy to clarify anything else.

Plain, polite, specific; one guideline per paragraph; no blame, no threats, no "other apps do it".

3. Apple guidelines apps and games hit most

  • 2.1 App completeness: crash on launch / during review (check the crash log in the message, test the review device class and OS), placeholder text or art, broken links, IAPs not working in the sandbox (Paid Apps agreement active? products READY_TO_SUBMIT and in the same submission?), features behind a login without a demo account (review-access skill: demo account in .storebound/credentials.json, storebound apple review-details sends it).
  • 2.3 Accurate metadata: screenshots must show the real app (for a game: real gameplay); no prices, no "free" claims for paid items, no other platforms' UI; keywords without competitor names; age rating answers that match the content.
  • 3.1.1 In-app purchase: digital goods only through IAP; a visible Restore Purchases for non-consumables; no links to outside payment; loot boxes must show odds.
  • 3.1.2 Subscriptions: the purchase screen shows title, length, price per period and what the user gets; links to the privacy policy and the Terms of Use (EULA) in the app and in the metadata; free trial terms clear. See store-subscriptions.
  • 4.2 Minimum functionality: a thin app (one screen, a tutorial-level loop) or a web wrapper. Add depth (for a game: levels, progression, offline play; for an app: native features, offline use, real utility). Explain what the user does in the notes.
  • 4.3 Spam: too similar to your own or others' apps (same template, reskins). See portfolio-originality; merge ideas instead of shipping near-duplicates. Hard to appeal without real differences.
  • 5.1.1 Data collection: privacy policy link in the listing and inside the app; only collect what you need; account deletion in-app if you have accounts (5.1.1(v), account-deletion skill).
  • 5.1.2 Data use / ATT: the App Tracking Transparency prompt before any tracking SDK reads the IDFA, a purpose string that says why, no incentive or pressure to allow, no tracking when denied.
  • Privacy label mismatch: App Privacy must match what the SDKs really collect (ads / analytics SDK docs list it). Update the label in App Store Connect (UI) and Publish; no new build needed for label-only fixes.

4. Google Play

  • Data safety mismatch: Play scans the SDKs in your AAB. Fix the form (storebound play data-safety) to include what the SDKs collect, or remove the SDK; then resubmit from Publishing overview.
  • Ads policy / disruptive ads: no interstitials at launch, on exit or mid-gameplay; close buttons visible; rewarded ads only opt-in. Ads must not imitate system UI.
  • Families: if the target audience includes children, only Families-certified ad SDKs, no ad id, teacher-approved rules. If the app is not for children, make sure store art and the target audience form say so.
  • Metadata: no keyword stuffing, no "best/#1", no unrelated keywords (aso-basics).
  • Strikes and suspensions: one policy strike affects the account; repeated strikes can terminate it. Fix first, then appeal from the notice with the change described. Do not upload the same app under a new package to dodge it.
  • Rejected updates: the previous version stays live; fix and send changes for review again.

5. After sending

  • storebound apple status --wait-review (exit 0 approved, 1 rejected, 7 timeout) or storebound play status.
  • Write down guideline, cause and fix in the project's docs so the next app does not repeat it.