Reading your rejection email: a field guide

Apple's rejection messages look intimidating and read like legal notices, but they follow a strict format. Once you know the format, you can pull the actionable part out of any rejection in about a minute.

The header line is a map reference

Every rejection leads with a line like:

Guideline 2.1 - Performance - App Completeness

Three parts, most specific to least:

The number, 2.1, points into Apple's App Review Guidelines, which are organized like a legal document: section, then subsection, sometimes deeper (3.1.2 is section 3, subsection 1, sub-subsection 2, and you'll occasionally see letters, like 4.3(a)). The number is the single most useful thing in the email; it's the exact rule Apple says you broke.

The section name, Performance, tells you which of the five top-level areas you're in. Apple's guidelines have exactly five: Safety (1), Performance (2), Business (3), Design (4), and Legal (5). This alone tells you the kind of problem: a 2.x is about the app working properly, a 3.x is about money, a 4.x is about what the app is and how it looks, a 1.x or 5.x is about content and law.

The title, App Completeness, is the human name of the rule. So "Guideline 2.1 - Performance - App Completeness" decodes to: section 2 (does the app work), rule 1 (it must be finished and functional), so the reviewer hit something broken, crashing, or placeholder. See our 2.1 guide for the full breakdown.

Where the actionable detail hides

The guideline citation is followed by boilerplate: a paragraph quoted straight from the guidelines, identical in every rejection under that rule. Don't spend long on it. The part written about your app comes after, usually under a phrase like "Specifically" or "Next Steps," and it's often just one or two sentences: the screen that crashed, the button that did nothing, the login that failed. Screenshots, when attached, are gold: they show you exactly what the reviewer saw, on what device.

If the specific part is thin or missing, that's information too. Some rejections, and 4.3 Spam is notorious for this, are largely template text because the objection is about the app as a whole, not one screen. When you can't tell what a message means, look up the guideline number it names in the rejection guides; each one starts from the exact wording Apple sends.

Where this conversation lives

The email is a copy. The real thread is in App Store Connect, on your app's page. Follow the unresolved issues link on your submission. Developers have long called this the Resolution Center; Apple's current interface presents it simply as messages from App Review, with a Reply to App Review button. Replies support attachments, which matters more than it sounds: a short screen recording of the "broken" flow working is often the fastest way to resolve a false alarm.

How to reply without making it worse

Answer the question they asked. If the rejection says the app crashed on launch on iPad, reply about the crash on iPad, not about your app's mission or how long you've worked on it.

Fix first, reply second. The strongest reply is "this is what we changed," written in past tense, as a short list. If you believe the reviewer is mistaken (they missed the demo account, the backend was briefly down) say so plainly and provide the evidence: credentials, steps, a recording.

Keep it short and civil. Reviewers handle many apps a day. Three paragraphs beat ten. Frustration in the thread never helps and stays on the record for the next reviewer who reads it.

Don't argue the rule itself in the thread. The reviewer applies the guidelines; they don't rewrite them. If you genuinely believe the guideline was misapplied, Apple has a separate formal appeal to the App Review Board. That's the venue for "we don't think this rule covers us," one appeal per submission.

Don't resubmit unchanged while a question is pending. Reply in the thread, then resubmit. Silent unchanged resubmissions read as ignoring feedback, and the thread history follows your app.

A one-minute triage, in order

1. Read the guideline number and section: what kind of problem is this?
2. Skip the boilerplate; find the "Specifically" sentence and any screenshots.
3. Look up the guideline. Our guides cover the rejections that hit AI-built apps hardest, with fixes and reply templates.
4. Fix, then reply with what changed, then resubmit.

A rejection is the review team telling you exactly what stands between your app and the store. Decoded calmly, it's the most specific to-do list you'll ever get.