You opened the Resolution Center, read the rejection text twice, and the citation still does not match the app you built. The thread with the assigned reviewer has gone quiet, and the only path left is the appeal to the App Review Board. A clean appeal letter, written as a punch list of facts rather than an argument, clears most cases that should never have been rejected in the first place.
Short answer
The short answer is that an App Review Board appeal works when Apple has misread your app, not when Apple has caught a real guideline issue. According to Apple's App Review page on appeals, the Board is the right tool when the developer believes Apple misunderstood the app's concept and functionality, or treated the submission unfairly. Apple's three requirements are blunt: state the specific reasons the app complies with the guidelines, submit only one appeal per submission, and respond to any pending Resolution Center requests first.
What you should know
- The Resolution Center comes first. The App Review FAQ on Apple Developer Forums tells developers to reply in the Resolution Center with information and screenshots before filing a Board appeal.
- One appeal per submission. Apple limits each rejected build to a single Board review; filing twice does not double the chance of a reversal.
- Citation, not argument. The Board reads guideline references. Reply with the sub-clause, the app's behavior, and the proof. Skip the emotion.
- Fourteen calendar days in practice. Apple's rejection messages typically include a line saying the developer can appeal within 14 calendar days from the rejection date, with the window resetting on each new submission.
- No promised timeline. Apple does not commit to a Board response time. Forum reports range from a few business days to several weeks.
- Resubmission is the faster path when a fix is possible. The Board is for cases where no change should be required.
When is an App Review Board appeal the right call?
The short answer is when the reviewer has applied a guideline that does not match what the app actually does. According to Apple's App Review page on the appeal channel, the Board exists for cases where developers believe Apple misunderstood the app or treated the submission unfairly, not for cases where the build has a real defect.
In practice, three rejection patterns appeal cleanly. The first is a guideline cited against a feature that does not exist in the build, often a leftover from a prior version. The second is a Guideline 4.3 design-spam rejection on an app that has unique functionality the reviewer missed during the test pass. The third is a 2.1 rejection on a build that does not crash on the developer's hardware, where the reviewer's test account or device combination produced the failure rather than the app code.
The honest answer is that an appeal does not work when the app has a real bug. A 5.1.1 Privacy Manifest gap, a missing in-app account deletion path, a broken sign-in, or a placeholder asset is a fix-and-resubmit problem. The Board reads the same guidelines and reaches the same conclusion the reviewer did.
The limit is that the bar for "unfair" is higher than it sounds. Threads such as the Apple Developer Forums discussion on appeal experience show developers waiting weeks for a Board decision that ultimately confirmed the original rejection. The Board is not a second roll of the dice.
How do you submit the appeal in App Store Connect?
The short answer is through the Contact the App Review Team form, not by replying again in the Resolution Center. The Resolution Center thread is for back-and-forth with the assigned reviewer; the Board is a different team reading the same record from a fresh seat.
The mechanism is short. Open App Store Connect, navigate to the rejected app, and open the rejection record in the Resolution Center to confirm the exact guideline citation and the rejection date. Then go to the Contact the App Review Team page and select "I would like to appeal an app rejection or app removal" from the topic drop-down. The form asks for the app name, the Apple ID of the developer account, the submission identifier, and the appeal text.
According to the App Review FAQ on the developer forums, Apple expects the appeal information to be specific about how the app complies with the published guidelines. Vague claims do not move the file forward. A sentence that quotes the rejection text and answers it with a guideline reference does.
The limit is the one-appeal rule. Filing twice on the same submission does not double the chance; it queues a duplicate and may delay the file. The first appeal has to count.
What goes in a clean appeal letter?
The short answer is four blocks: the app and rejection citation, the rejection sentence quoted, what the app actually does, and the request. Keep the letter under 400 words.
Block 1 names the app and the rejection. Example: "App: Mango Reader. Submission: 1.0.7 (build 142). Rejection date: 2026-05-12. Guideline cited: 4.3(a) Design Spam."
Block 2 quotes the rejection. Lift the exact sentence from the Resolution Center so the Board reads the same words the reviewer wrote. This anchors the appeal to a specific reading rather than the developer's interpretation of the message.
Block 3 explains the build's behavior in declarative language. State what the user sees on screen, which files or APIs are unique to this app, and what differentiates the build from any pattern Apple may have flagged. Reference test credentials, video timestamps from the App Review Information section, and any prior approval history of the same app under the same guideline.
Block 4 is the request. "I respectfully ask the App Review Board to re-evaluate this submission under Guideline 4.3(a)." Nothing more.
Here is a working template:
Hello App Review Board,
I am writing to appeal the rejection of [App Name], submission [Version (build)], dated [Date]. The rejection cites Guideline [number], and the Resolution Center message reads, "[quoted sentence]."
[App Name] is [one-sentence description of what the app does]. The functionality the reviewer flagged is [name the feature]. In practice, [describe the behavior the user sees, referencing screens or files by name]. The aspect that distinguishes this build from any pattern Apple has previously flagged under Guideline [number] is [one or two specific facts: a unique data source, a licensed integration, a specific certificate profile, a custom algorithm].
Supporting evidence: the demo account in App Review Information ([username]) is configured to reach the relevant screen in two taps. A walkthrough video is attached to this submission's notes.
I respectfully ask the Board to re-evaluate this submission. I am happy to provide any further information.
Best, [Name] [Apple Developer Account Email] [Team ID]
The limit is tone. The Board reads dozens of appeals a day. A letter that reads as a legal complaint or a marketing pitch gets the same review window as a calm one, with worse outcomes.
How do Resolution Center replies and Board appeals compare?
The short answer is that the two channels look similar but reach different teams and answer different questions. The Resolution Center is a continuation of the original review; the Board is a fresh read.
| Question | Resolution Center reply | App Review Board appeal |
|---|---|---|
| Audience | Same reviewer who issued the rejection | Different team, reading the record fresh |
| Use when | A fix shipped, a clarification helps, screenshots prove behavior | The reviewer applied the wrong guideline or missed evidence |
| Limit per submission | Multiple replies allowed within the open thread | One appeal only |
| Typical response | Often within 24 to 48 hours | No promised timeline, days to weeks |
| Best for | Fix-and-clarify cases, sub-clause disagreements | Genuine misreads where no build change is required |
| Closes when | The reviewer accepts the change or escalates | The Board overturns, confirms, or requests more information |
The limit is that the two channels are not interchangeable. A Board appeal filed while the Resolution Center thread is still open looks premature and may be returned with a note to use the original thread.
How long does the App Review Board take to respond?
The short answer is no published timeline. Apple's standard acknowledgement reads along the lines of, "the App Review Board will contact you directly once they have completed their investigation. Thank you for your patience."
In practice, the Apple Developer Forums thread on appeal timelines reports responses ranging from three business days to several weeks. Cases that turn on a major guideline interpretation (4.3 design, 5.1.1 privacy, 4.0 design quality) tend to run longer than cases involving a clear factual misread by the original reviewer.
A Board decision typically does one of three things. It overturns the rejection and clears the build for App Store release. It confirms the rejection and explains the reasoning in language specific enough to guide the next submission. Or it requests more information through the Resolution Center, which restarts the conversation.
The limit is that a long Board wait can be worse than a quick rebuild. If a small change can resolve the rejection, the developer rebuild is usually faster than the appeal. Reserve appeals for cases where no change should be needed and the citation is the dispute.
What to watch out for
Three traps appear in almost every Board appeal cycle.
The first is appealing while a Resolution Center thread is still open. Apple's stated process is to use the Resolution Center first. Filing a Board appeal before answering an open question from the reviewer adds friction and may pause both threads.
The second is changing the build during an open appeal. Uploading a new binary withdraws the current submission from review, which voids the appeal on that submission. Decide between fix-and-resubmit and appeal; doing both at once is rarely the right move.
The third is the long quote-back. Letters that copy three paragraphs from the App Review Guidelines waste the Board's reading time. Quote one sentence from the rejection, one sentence from the guideline if needed, and put everything else in the supporting evidence section.
Key takeaways
- Use the Resolution Center first; the Board is the second step, not the first.
- Treat the appeal letter as a punch list: citation, quoted rejection, behavior, evidence, request.
- A real bug is a resubmission case, not an appeal case.
- Submit only one appeal per rejected submission, and answer any pending Apple questions before filing.
- For builders who want an outside read on what their compiled build actually contains before the next submission or appeal, PTKD.com (https://ptkd.com) is one platform focused on pre-submission scanning aligned with OWASP MASVS for no-code and AI-coded apps.
