What an App Store rejection actually costs

The arithmetic of a cycle

The two bolded rows dominate, and both are worse for configuration rejections than for content ones. A content rejection ("your screenshot shows a competing platform") tells you exactly what to change. A configuration rejection tells you a guideline number, and for a React Native project with 800 packages that is a search problem.

Why React Native and Expo take more cycles

Three structural reasons, none of which are anyone's fault.

The offending code is usually not yours. Required-reason API usage comes from hermes, from Firebase's transitive pods, from image caches and SQLite wrappers. Apple's rule is per-bundle — each executable or dynamic library that uses a required reason API needs a manifest in its own bundle — so your app's manifest cannot cover them. ITMS-91053 in detail.

The generated project is not the source of truth. With Expo's continuous native generation, editing ios/ directly gets overwritten at the next prebuild. A fix that works locally and vanishes on the build server is a whole wasted cycle, and it is a very common one.

Permission strings come from packages. An NSLocationAlwaysAndWhenInUseUsageDescription can appear in your Info.plist because a config plugin put it there, describing a feature you removed six months ago. Apple reads it and asks why an app with no map needs background location. That is a Guideline 5.1.1 or 5.1.5 conversation you did not know you had started.

The rejections a machine can catch before you submit

These are deterministic, they live in files, and there is no judgement involved:

• Privacy manifest completeness — required-reason API categories used with no declared reason (ITMS-91053), and listed SDKs with no manifest at all (ITMS-91061).
• Permission strings that describe features you no longer ship — an Info.plist purpose string with no corresponding code path.
• UIBackgroundModes declared without a matching feature — Guideline 2.5.4 rejects apps declaring the location background mode without a genuine persistent-location feature.
• Missing in-app account deletion where the app supports account creation — Guideline 5.1.1(v).
• Placeholder content — lorem ipsum, TODO, example.com URLs, a privacy-policy link that 404s.
• Metadata that names other mobile platforms — Guideline 2.3.10.
• Play Data safety inconsistencies — a declared form that does not match what the manifest and SDKs actually do.
• Target API level — new Android apps must target the required API level by Google's annual deadline.

The rejections a machine cannot catch are the judgement ones: whether your app has enough functionality to justify existing (4.2), whether it reads as spam (4.3), whether your subscription paywall is honest (3.1.2). Those need a human, and any tool claiming otherwise is overselling.

Why the second and third cycles happen

The first rejection is unavoidable sometimes. The second and third are usually caused by one of three things.

Fixing the symptom rather than the bundle. Adding a UserDefaults reason to your app's manifest when the usage was in a framework. It looks fixed. It uploads. It fails identically.

Declaring defensively. Adding every reason code in a category "to be safe." Apple's wording is that declared reasons must "accurately reflect your use" and that you may use the API and derived data "for the declared reasons only" — several codes bind you to conditions such as never sending the data off-device. Over-declaring is a misdeclaration. The full reason-code reference.

Not answering the reviewer. A silent resubmission gives the reviewer no reason to look at it differently. A Resolution Center reply that names the clause, states what changed and where, and answers the actual question is materially more likely to clear on the next pass.

What to do instead

1. Run a static check before you build, not after you are rejected. Everything in the deterministic list above is findable in the repository.
2. Fix in the right bundle. For dependency-sourced findings, the fix is upstream: update, fork, replace or remove.
3. Write review notes that pre-empt the obvious question. If you declare background location, explain the user-facing feature that needs it, in the notes, before anyone asks.
4. Keep a demo account that works and check it the morning you submit. A broken demo login is a Guideline 2.1 rejection and it is entirely self-inflicted.
5. Reply properly when you are rejected. Cite the clause, state the change, name the file.

That first step is what shipcheck is: a scan that runs inside your own Claude Code session, reads the project locally, cites the exact clause, predicts what the reviewer will say, and names the file. No account, no repository upload, first scan free with real findings. What shipcheck checks.

Questions and answers