Rejected: the order of operations that gets you approved fastest

Step one: separate the citation from the story

A rejection typically contains a guideline number, a sentence or two of what the reviewer observed, and sometimes a screenshot.

Write down, literally:

• The guideline number.
• The reviewer's exact words about what they saw.
• What screen or step they were on.

Then ask whether the observation is true. Not whether the guideline is fair, and not whether other apps do the same thing. Whether what they described actually happens in your build. Reproduce it on a device, using the build you submitted, with a fresh install and a fresh account.

Half the time the observation is true and slightly different from what you assumed. That difference is the fix.

Step two: which of the three is it

Fix if reproducing it shows a real problem. Change it, then keep going: run the full pre-submission pass before you upload, because the reviewer stopped at the first thing. The first-submission checklist.

Clarify if the app behaves correctly and the reviewer could not get there. Common causes: a demo account that expired or was rate limited, a feature that needs server-side data the account does not have, a flow requiring a physical device capability, a paywall in front of the thing they were asked to evaluate. Reply with exact steps, working credentials, and a short screen recording. Review notes that work.

Appeal if the guideline does not apply to what your app does and you can demonstrate it. An appeal is a factual argument: here is the screen, here is the code path, here is the recording showing the behaviour they described does not occur. Appealing because you think the rule is wrong is a different activity and it does not work.

What to write in the Resolution Center

Short, specific, and structured so a busy person can act on it:

Thanks for the review.

What changed / what we found:
- [one line per item]

To reproduce the feature in question:
1. Sign in with [email protected] / [password]  (verified working today)
2. Tap Practice on the home screen
3. The subscription flow appears at step 3

The permission cited at 5.1.1 is used only for [specific feature], on
[specific screen]. Screen recording attached.

Three things make this work. Working credentials, verified today. Numbered steps to the exact screen. One line per item, so nothing has to be extracted from a paragraph.

What does not work: explaining your roadmap, arguing about other apps, apologising at length, or writing three paragraphs where four lines would do.

The moves that cost you a week

Uploading a build to answer a question. A message would have done it in hours.

Fixing one thing when you can see three. You will meet the other two, one review cycle each.

Changing the app to match your theory of the rejection rather than the observation. Reproduce it first.

Removing the feature instead of fixing it, when the fix was a purpose string or a disclosure. You lose the feature and often still fail on something adjacent.

Expedited review for a slipped launch date. It exists for genuinely urgent situations. Spending it here means not having it when a live bug is hurting users.

Resubmitting the same build with a longer explanation. If the observation was true, an explanation does not change it.

Google Play is a different shape

Play rejections and policy notices are typically more precise about the offending element and more automated in the first pass. The corresponding moves:

• Read the policy name, then find the specific declaration or asset it refers to: the Data safety form, a permissions declaration, a listing asset, a target API level.
• Check the release blocking list in the Console for that version rather than reasoning from the email.
• If it is a Data safety mismatch, the fix is almost always the form, not the app: the form is a declaration about behaviour, and it is compared against what the app actually does. Play Data safety.
• Closed testing requirements and target API level are hard gates, not judgement calls, and no explanation moves them. Closed testing. · Target API level.

Before you resubmit

Run everything, not just the cited item:

# purpose strings with no matching feature
grep -rn 'UsageDescription' ios/*/Info.plist app.json app.config.js 2>/dev/null

# other-platform references in metadata and UI strings
grep -rniE 'android|google play|play store' fastlane/metadata src app 2>/dev/null | head

# account creation without deletion
grep -rniE 'delete (my )?account|deleteAccount' src app 2>/dev/null | head

Then check the four upload-time blockers, which are decided before a human ever sees the build: ITMS-90683, ITMS-91053, ITMS-91054/5/6, ITMS-91061.

A rejection is a cycle, not a verdict. The cost is time, and the way to spend less of it is to make each submission carry every fix you could have found. What a rejection actually costs.

shipcheck runs that whole pass from inside Claude Code, cites the guideline for each finding and names the file and line, so the resubmission carries more than the one thing you were told about. What it checks.

Questions and answers