Why apps get rejected, and how to answer

A rejection is not a verdict. Most are procedural, most are answerable, and the response matters as much as the fix.

2.1 — Performance: App Completeness

The most common rejection and the least interesting. Crashes on the reviewer's device, placeholder content, broken links, or a feature the reviewer could not reach. Frequently it is a demo account that does not work, or a backend that was not reachable from the review team's network.

How to answer: fix it, and give the reviewer explicit step-by-step notes plus working credentials.

4.3 — Design: Spam

Your app is too similar to something else, often something you also published. This catches template-built apps and portfolios of near-identical white-label products.

How to answer: show what is substantively different. If the answer is "nothing", the fix is product work, not correspondence.

5.1.1 — Data Collection and Storage

Collecting more than the app needs, requiring registration for features that don't need an account, or missing the account-deletion path — which is mandatory for any app offering account creation.

How to answer: remove what you don't need, make sign-in optional where the feature allows it, and ship deletion in-app.

3.1.1 — In-App Purchase

Digital goods sold outside Apple's payment system, or linking out to your own checkout. The rules here are specific and enforcement is inconsistent, which is what makes it frustrating.

Writing the response

Be short, be specific, address the exact guideline cited, and say what changed. Reviewers read a lot of these. Argument without a change rarely moves anything; a change with a clear one-paragraph explanation usually does.

Escalating

The Resolution Center is the first stop. App Review Board appeals exist for genuine misapplications of a guideline, and they work — occasionally.

Help with a live rejection

App Store submission covers exactly this, and app rescue covers the case where the app has been stuck for months.