On this page (12 sections)
The four responses, and which one you need
| Response | Use when | Where |
|---|---|---|
| Fix | The finding is correct: bug, missing feature, privacy or payment issue | New build via App Store Connect |
| Reply | The reviewer asked a question, or misunderstood something you can clarify | The review thread for the version |
| Resubmit | Metadata Rejected, or only notes / credentials changed | App Store Connect, same build |
| Appeal | The decision is wrong on the facts and you can prove it | App Review appeal form |
Clarification first
If the message ends with questions, or reads like the reviewer did not understand the app, reply in the thread first. Explain what the app does, point to the feature, attach screenshots or a short video. Reviewers frequently approve after a clear reply. An appeal filed while questions are unanswered looks like an attempt to skip the conversation.
When an appeal is strong
- The reviewer cited a guideline that does not apply to what the app does, and you can show what it does.
- The reviewer states something factually incorrect (a permission the app does not request, a claim the listing does not make, a payment path that does not exist).
- An exception in the guideline genuinely applies (for example a 3.1.3 category) and the rejection did not account for it.
- You have documentation: licences, authorisations, regulatory approvals, proof of ownership.
When an appeal is weak
- The finding is right and you would prefer it were not (most 4.2 and 4.3 cases).
- The argument is that your business depends on approval, or that other apps do the same thing.
- You cannot point to specific evidence, only to your own description of the app.
- The same build has been rejected for the same reason more than once.
Answer outstanding questions before appealing
If Apple asked for information and you appeal instead of answering, the appeal is likely to be returned to the review thread. Answer completely, then appeal only if the decision after your answer is still wrong.
Guideline-specific evidence
| Guideline | Useful evidence |
|---|---|
| 2.1 | Crash-free test on the cited device / OS (video), backend availability logs, working demo credentials |
| 2.3 | Screenshots captured from the build showing the claimed features |
| 3.1 | Which exception applies and why: physical goods, reader app, enterprise, region-specific entitlement documentation |
| 4.2 | A concrete list of native functionality with screenshots or video |
| 4.3 | A comparison matrix against the apps Apple considers similar |
| 5.1 | The privacy policy, labels, manifest and purpose strings showing consistency; ATT flow video |
| 5.2 | Trademark licences, authorisation letters, ownership documents |
Structure and tone
- One sentence: what was rejected and under which guideline.
- One paragraph: what the app actually does, in plain terms.
- The specific point where the decision diverges from the facts.
- The evidence, attached or linked.
- What you are asking for.
Keep it under a page. Factual, polite, no rhetoric, no threats, no references to competitors.
Never fabricate
Doctored screenshots, invented testing data, fake licences or misrepresented functionality in an appeal are far worse than a rejection. Apple can terminate developer accounts for dishonest submissions.
Repeated rejections
If the same guideline has been cited three times, the problem is not the reviewer. Stop resubmitting, do a full review against the guideline, and change the app. Repeated identical submissions can be treated as spam.
Metadata-only situations
Metadata Rejected decisions rarely need an appeal: correct the listing and resubmit. Appeal only if the reviewer’s reading of the metadata is demonstrably wrong.
Expedited review vs appeal
An expedited review request is for time-critical situations (a critical bug fix, a time-sensitive event) and is not a way to escalate a rejection. An appeal is about the decision. They are separate requests with separate forms; do not use one to achieve the other. When the situation genuinely is a critical fix waiting in the queue, see how to request an expedited review.
Appeal-readiness checklist
- All reviewer questions answered in the thread
- You can state, in one sentence, the specific factual error
- Evidence attached, and it is real
- The app has not been resubmitted unchanged for the same reason multiple times
- The appeal is short and specific
We do not publish or estimate appeal success probabilities. Nobody outside Apple can. What we can do is tell you honestly whether your case has the substance an appeal needs.
How we help before you appeal
Before an appeal is written we check whether the rejection is actually a reviewer error or a real gap: we reproduce the finding on the cited configuration, read the guideline clause against the app, and answer any open reviewer question with evidence. If a technical change is the honest fix, we implement it and you resubmit instead of appealing. If the case is genuinely strong, we help you keep the appeal short, factual and evidence-backed. We never fabricate evidence, never promise an outcome and never recommend an appeal we would not make ourselves.