How to Write an App Store Rejection Appeal Letter That Actually Works
A rejection appeal letter is a written response you submit to Apple — either in Resolution Center or to the App Review Board — explaining why your app actually complies with the guideline it was rejected under, backed by specifics. It's not a plea for mercy; it's a technical rebuttal, and it only works if it reads like one.
Most developers write appeals the way they'd write a customer support ticket: frustrated, a little defensive, asking for a human to "please take another look." Apple's reviewers see thousands of those. They don't move the needle. What moves the needle is a document that cites the exact guideline number, shows the reviewer's stated concern doesn't match what's actually in the build, and gives them a low-effort way to say yes.
That reframe matters because Apple's review process treats rejections as guideline violations, not judgment calls open to negotiation. Your job isn't to argue that the rule is wrong or unfair — it's to demonstrate, with evidence, that your app already satisfies it, or to show precisely what changed once you fixed it. Reviewers approve appeals when they can verify a claim in under a minute. They reject appeals that require them to re-adjudicate your whole app.
This article gives you a working template for the appeal letter itself, guideline-specific language for the rejections that generate the most appeals (metadata, privacy, IAP, screenshots), and the escalation path if Resolution Center doesn't resolve it — including when and how to involve the App Review Board. If you want to see what a clean, reviewer-ready submission looks like before you're in this situation, the sample report shows the same evidence-first format applied preemptively, before submission instead of after rejection.
Key takeaways
- The App Review Board only overturns rejections where a guideline was misapplied to facts, not cases where a developer merely disagrees with the policy itself.
- An effective appeal cites the exact guideline number (e.g., "Guideline 2.3.1") in its first sentence and stays under 200 words, since longer appeals read as uncertain to reviewers processing hundreds per day.
- Resolution Center replies typically come back within 24–48 hours, while App Review Board escalations can take several business days to a couple of weeks.
- If the reviewer's rejection is factually correct, fixing the build and resubmitting is almost always faster than appealing, since Apple's Board doesn't overturn valid rejections.
- Appealing does not hurt future submissions — Apple has stated appeal history isn't held against a developer's account — but repeatedly resubmitting the same unfixed violation does.
Appeal vs. Resubmission: Which One Do You Actually Need
Before you write anything, figure out which of three paths actually fits your rejection — because using the wrong one wastes a review cycle, and review cycles are the thing you can't afford to waste.
Option 1: Reply in Resolution Center. This is a message thread attached to your specific rejection, visible in App Store Connect under your app's status. Use this when you believe the reviewer misunderstood something about your app — misread a screen, tested the wrong flow, or flagged something that isn't actually present in the build. It's fast (often a response within 24–48 hours), low-friction, and doesn't require a formal case. This is the right first move for the majority of rejections, especially anything involving Guideline 2.1 (App Completeness) or metadata mismatches.
Option 2: Formally appeal to the App Review Board. This is a separate, heavier process you invoke when Resolution Center has failed — you've replied with clear evidence and the reviewer still disagrees, or you believe the guideline itself was misapplied to your specific case. The Board reviews the guideline interpretation, not just the technical facts. It takes longer (Apple doesn't publish an SLA, but expect several business days to a couple of weeks) and it's a one-shot: come in with your strongest evidence the first time, because a second appeal on the same issue rarely gets traction.
Option 3: Just fix it and resubmit. No appeal, no argument — you agree the rejection is valid, you make the change, and you submit a new build. This is almost always the fastest path back into the App Store, and it's the right call more often than developers want to admit. If the reviewer is correct — your privacy nutrition label is missing a data type, your IAP restore button is missing, your permission string doesn't explain the use case — arguing about it costs you a review cycle you'd spend fixing it instead.
The rule for choosing: ask yourself one question — is the reviewer factually wrong about what's in my build, or right? If they're wrong (misread a screen, tested against a cached build, missed a flow that's actually there), reply in Resolution Center with a screen recording or annotated screenshot as evidence. If they're right but you believe the guideline itself doesn't apply to your case — a judgment call about a gray area, not a factual dispute — that's when you escalate to the App Review Board. If they're simply right, skip the appeal entirely and fix it.
A common miscalibration: treating every rejection as appeal-worthy. Reviewers reject a lot of apps for accurate, boilerplate reasons — missing metadata Apple can't infer, a permission description that doesn't state its purpose, an account deletion flow that isn't self-service. Appealing those doesn't just fail, it burns time you'd have spent shipping the fix. Two of the most common categories worth checking against your own rejection before you appeal: missing metadata around subscriptions (common with RevenueCat integrations that leave App Store Connect fields blank), and permission strings that don't pass Apple's "explain why" bar (a frequent issue in Expo apps using default or auto-generated permission descriptions). If your rejection matches one of these patterns, resubmission — not appeal — is almost certainly your fastest path back into review.
Decode the Rejection Before You Write Anything
Every rejection notice in App Store Connect contains one thing that matters more than the reviewer's prose: the guideline number. Everything else — the boilerplate, the tone, the vague "we found that your app..." framing — is secondary. If you write an appeal without first isolating that number, you're arguing with a feeling instead of a rule.
Find the exact guideline number
Open the rejection in the Resolution Center and look for the citation, usually formatted like "Guideline 2.3.1 - Performance - Accurate Metadata" or "Guideline 5.1.1(v) - Legal - Privacy - Data Collection and Storage." That number is your entire frame of reference for the appeal. Not the summary paragraph above it, not the screenshot the reviewer attached — the number.
Pull up the actual guideline text on Apple's App Review Guidelines page and read it verbatim, not from memory. Guidelines get revised, and reviewers cite subsections that carry specific requirements you may have missed. A rejection citing 2.3.1 (inaccurate metadata) is a completely different problem than one citing 3.1.2 (subscriptions), even if both showed up because your app has an in-app purchase. Confusing the two wastes your one shot at a focused appeal. If the rejection touches metadata language or screenshot claims, cross-check against what you actually submitted — our sample report shows what a pre-submission scan flags for exactly this category, so you can see the gap in your own listing before you write a word to Apple.
Decide if it's a bug or a policy disagreement
Once you have the number, sort the rejection into one of two buckets.
Bug: the app crashed, a button didn't work, a required disclosure was genuinely missing, or your permission strings didn't match Apple's requirements. If the reviewer is technically correct, don't appeal — fix it and resubmit. Appealing a real bug burns your credibility and the clock. This is common with permission descriptions in cross-platform apps; if you're on Expo, see our breakdown of Expo App Store permission description requirements, since the generated defaults frequently trigger 5.1.1 rejections.
Policy disagreement: the reviewer applied a guideline to a case it wasn't designed for, misunderstood your app's functionality, or made a judgment call you can counter with evidence — a demo video, a walkthrough, or a specific line from the guidelines showing your feature is compliant. This is where an appeal has a real chance. You're not asking Apple to change the rule. You're showing the reviewer misapplied it to your specific case.
Getting this classification wrong is the single biggest reason appeals fail. Reviewers can tell within the first sentence whether you understood what was actually flagged.
The Anatomy of an Appeal Letter Apple Reviewers Actually Respond To
App Review handles thousands of appeals a week through the Resolution Center. Reviewers skim. A letter that reads like a legal brief or an emotional plea gets the same outcome: rejected again, often by a different reviewer who has even less context than the first. The letters that get overturned share a structure, and it's shorter than most developers expect.
Lead with the guideline number
Your first line should state the guideline number and your position in one sentence. Something like: "Guideline 2.3.1 was cited for inaccurate metadata, but the screenshots submitted reflect the current build's functionality." No greeting, no preamble, no "I hope this message finds you well." The reviewer reading your appeal needs to know in five seconds which guideline you're contesting and why — they're often not the same person who rejected you, and they have no memory of your app.
This also signals that you've read the actual guideline, not just the summary email. Reviewers can tell the difference immediately, and it changes how carefully they read the rest.
State evidence, not frustration
The body of the letter is one paragraph. It contains facts a reviewer can verify without opening a second tab: a specific screen name, a build number, a timestamp in an attached video, a line from the guideline text that supports your reading. "This feature has worked correctly since build 42, demonstrated in the attached 30-second screen recording starting at the account settings screen" does more work than three paragraphs explaining how much this delay is costing your small team.
Skip the frustration entirely — not because it's unprofessional, but because it's not evidence and it doesn't move the guideline number. If the rejection stems from missing metadata around a purchase flow, check whether it maps to a known pattern; our note on RevenueCat missing metadata App Store rejections covers a specific version of this that's easy to misdiagnose as a policy disagreement when it's actually a straightforward fix. Similarly, if the citation involves account deletion flows, Apple's 5.1.1(v) requirements are exact about what has to be reachable and how — see App Store account deletion in Expo if that's the thread you're pulling.
Keep it under 200 words
Long appeals read as uncertain. If you need four paragraphs to explain why the reviewer was wrong, you're probably not as certain as you think, and the reviewer will sense it. Aim for under 200 words: guideline number and position, evidence paragraph, requested outcome. End with a direct ask — "Please re-review build 47 against Guideline 2.3.1" — not an open-ended request for clarification.
Apple's own guidance for the App Review Board escalation path rewards the same brevity. If your first appeal in the Resolution Center doesn't land, a short, evidence-backed letter is also what you'll resubmit to the Review Board — so get the format right the first time rather than padding it out on the second attempt.
App Store Rejection Appeal Letter Template
Resolution Center gives you one message box and no formatting tools. Structure still matters — reviewers skim, and a wall of unbroken text reads as defensive. Use this template as your starting point:
Subject: Appeal — [App Name] v[Version], Submission ID [XXXXXXXX]
We're requesting reconsideration of the rejection under Guideline [X.X.X].
What we understood the concern to be:
[One sentence restating the rejection in your own words — proves you read it]
What we changed:
[2-4 bullet points, each naming the specific screen, string, or config
that changed, not a general description of "improvements"]
Why this resolves the guideline concern:
[1-2 sentences connecting your change directly back to the guideline
language Apple cited]
Supporting evidence:
[Screenshot references, build number, or a link/attachment showing
the fixed behavior]
We're happy to provide additional detail or a demo account if useful.
Here's the template filled in for a real case — a photo-editing app rejected under Guideline 5.1.1 for requesting camera access without an in-context explanation:
Subject: Appeal — LumaEdit v2.3, Submission ID 91827364
We're requesting reconsideration of the rejection under Guideline 5.1.1.
What we understood the concern to be:
The camera permission prompt appeared before the user had chosen to
take a photo, with no explanation of why LumaEdit needs camera access.
What we changed:
- Moved the permission request to trigger only when the user taps
"Take Photo" inside the editor
- Updated NSCameraUsageDescription to read: "LumaEdit needs camera
access so you can capture a new photo to edit directly in the app."
- Added an in-app pre-permission screen (see screenshot 2) explaining
the feature before the system prompt appears
Why this resolves the guideline concern:
The permission request is now tied to a specific user action and
explains its purpose before the system dialog fires, matching the
"clear reason" requirement in 5.1.1.
Supporting evidence:
Attached: before/after screenshots of the permission flow, build 2.3.1
(41).
We're happy to provide additional detail or a demo account if useful.
Notice what's absent: no apology, no "we've been working hard on this app," no argument about whether the rule is fair. Reviewers process hundreds of these a day — they're checking whether the specific technical claim is true, not evaluating your tone.
Before you paste your version in, sanity-check the evidence section against what a thorough review actually looks like. Our sample report shows the level of specificity — exact file, exact string, exact screen — that separates an appeal that gets read carefully from one that gets a form-letter denial.
Wording the Appeal for the Rejections That Repeat Most Often
Most appeals fall into four buckets. Here's wording you can adapt for each, built around the guideline language Apple actually cites.
Missing or inconsistent metadata (Guideline 2.3.1)
2.3.1 rejections usually mean your screenshots, description, or preview don't match what the build actually does — a feature shown in a screenshot that's paywalled, or a description promising functionality not present in the reviewed build. Your appeal needs to name the exact mismatch and the exact fix:
What we changed:
- Removed the "offline mode" claim from the app description (this
feature ships in v2.4, not the current build)
- Replaced screenshot 3, which showed a subscription-only view, with
a screenshot of the free-tier experience
Don't argue that the discrepancy is minor. Fix it, state exactly what changed, and move on. If RevenueCat-driven paywalls are part of what triggered the mismatch — a common cause when subscription state isn't reflected consistently across your store listing — our breakdown of RevenueCat missing metadata App Store rejections covers the specific fields reviewers check.
Permission strings that don't explain themselves (Guideline 5.1.1)
The fix is almost always the same shape: tie the request to a user action, and make the usage description specific to what your app does with that data.
Why this resolves the guideline concern:
The updated NSLocationWhenInUseUsageDescription now states the exact
feature ("to show nearby stores on the map") rather than a generic
"LumaEdit uses your location," and the prompt only fires when the
user opens the map tab.
If you're on Expo, the managed workflow makes it easy to ship a generic, auto-generated permission string without noticing — that's a frequent cause of this exact rejection. See Expo App Store permission description for how to set these correctly in app.json before you resubmit.
In-app purchase and subscription configuration (Guideline 3.1.2)
3.1.2 rejections cover missing subscription terms, absent restore-purchase functionality, or IAP metadata that doesn't match what's configured in App Store Connect. State plainly what was missing and where it now lives:
What we changed:
- Added a visible "Restore Purchases" button on the Settings screen
- Added subscription length, price, and auto-renewal terms directly
above the purchase button, per 3.1.2
If your paywall is RevenueCat-driven, double-check that the product identifiers and pricing shown in-app match what's live in App Store Connect — a mismatch here is one of the most common 3.1.2 triggers. The RevenueCat missing metadata App Store guide walks through the exact fields to verify.
Account deletion requirements (Guideline 5.1.1(v))
Apps with account creation must offer in-app account deletion, not just a link to a web form or a "contact support to delete" message. Your appeal should point directly to the new deletion path:
What we changed:
- Added an in-app "Delete Account" option under Settings > Account,
which permanently deletes the user's data without requiring an
external website or support ticket
This one trips up Expo apps disproportionately, since the deletion flow often needs a native module or a backend endpoint that isn't scaffolded by default. Our App Store account deletion Expo guide covers the implementation pattern that satisfies 5.1.1(v) without a full backend rebuild.
Mistakes That Get a Second Rejection
Most second rejections aren't caused by a weak argument — they're caused by an appeal that never addresses what the reviewer actually flagged.
Arguing tone instead of facts. "This is unfair" or "your reviewer clearly didn't test this" reads as a complaint, not a case. Reviewers reject apps by the hundreds a day; nobody escalates a rejection because the developer sounded frustrated. Example: an appeal that opens with "I've been a developer for 10 years and never had this problem" gets denied on the same guideline citation, because it never explains why the rejection was a misapplication.
Citing the wrong guideline. If Apple rejected under 2.3.1 (metadata mismatch) and your appeal argues against 5.1.1 (data collection), you've written a rebuttal to a rejection you didn't get. This happens most often when developers skim the rejection instead of reading the exact guideline number in Resolution Center. Cross-check the number against the App Store Review Guidelines before drafting a single sentence — see Decode the Rejection Before You Write Anything above for how to do this properly.
Appealing without fixing the underlying issue. If the rejection is correct — the privacy label really doesn't match what the SDK collects, or the delete-account flow really is missing — an appeal buys you nothing. Apple's App Review Board doesn't overturn valid rejections; it only overturns misapplied ones. Example: a rejection under 5.1.1(v) for missing account deletion, appealed with "we'll add it in the next release," gets denied — the guideline requires the feature to exist now, not a promise. If you're on Expo and hit this specific one, fix it first using a pattern like App Store Account Deletion Expo, then resubmit — don't appeal a correct rejection.
Resubmitting when an appeal was the right move. The inverse mistake costs more time. If a reviewer rejected a permission string as vague under 5.1.1 but your string actually meets the requirement, resubmitting the same build without comment just re-triggers the same review path and the same rejection. That's a wasted cycle — you needed an appeal explaining why the existing text already complies, not a new build. This is common with Expo permission descriptions; see Expo App Store Permission Description for wording that satisfies reviewers the first time.
The pattern underneath all four: reviewers and the App Review Board respond to a precise claim tied to a specific guideline number, backed by evidence (a screenshot, a code snippet, a policy quote) — not sentiment, not the wrong citation, not an unfulfilled promise, and not silence when a real correction is owed.
If the Appeal Fails: App Review Board and Beyond
A denied appeal in Resolution Center isn't the end of the process — it's the point where you decide whether to escalate formally.
Requesting App Review Board escalation. If your first appeal is denied and you still believe the rejection misapplies a guideline, you can request a review by the App Review Board directly from the same rejection message in App Store Connect, or via the Feedback form referencing your app and submission ID. Be specific about which prior response you're escalating and why the reasoning given wasn't sufficient — repeating your original appeal verbatim doesn't help.
Realistic timelines. A standard appeal response in Resolution Center typically comes back within 24–48 hours. Board escalation takes longer — commonly several business days to a week, sometimes more during peak submission periods (post-WWDC, holiday season). If you're on a launch deadline, factor this in before you escalate rather than after.
When persisting stops being worth it. Escalate only when the guideline was genuinely misapplied and you have concrete evidence: a screenshot showing the feature already exists, a quote from the exact guideline text that supports your reading, or a prior approval of the same pattern in an earlier build. If your case boils down to disagreeing with Apple's policy itself — rather than its application to your app — the Board isn't going to rule in your favor, and a second escalation attempt just burns more days off your timeline.
In practice, most apps are better served by fixing and resubmitting than by a second round of appeals. A resubmission with the issue actually corrected clears review in the normal cycle — often faster than a Board escalation resolves. Reserve escalation for cases where you're confident the rejection was wrong, not just inconvenient. If you want a second pair of eyes before you decide which path to take, a sample report shows what a pre-submission catch looks like for the same categories — metadata, screenshots, privacy, IAP — that drive most of these disputes in the first place.
Catch the Rejection Before It Happens
Here's the uncomfortable part: most appeal letters shouldn't need to exist. If you're writing one, something shipped that a five-minute check would have flagged — a permission string that doesn't match its usage, a missing privacy label, a restore purchases button that's one tap too deep. Apple's reviewers aren't looking for reasons to reject you, but they are fast, literal, and unforgiving of gaps between what your app says it does and what it actually does. Guideline 2.1, 5.1.1, and 3.1.1 rejections in particular tend to trace back to the same handful of preventable oversights, over and over, across thousands of indie submissions.
The fix isn't a better appeal letter. It's not submitting the broken build in the first place.
That's the entire premise behind the App Store Preflight Kit — a Markdown-first skill pack built to run against your app before you hit submit, not after Apple tells you what you missed. It checks the stuff that actually causes rejections: metadata consistency, screenshot compliance, privacy manifest and permission-string alignment, IAP configuration against App Store Connect. No dashboard, no account, no black box — you run it, it tells you what a reviewer would flag, in language that maps directly to the guideline number they'd cite.
If you want to see what that actually looks like before you commit to anything, the sample report shows a real run against a real app — the exact kind of issue it catches, and how it's written up. It reads a lot like the rejection notices in the previous section, except you get it before submission instead of after.
The math is simple: a rejection costs you a review cycle, which on a bad week is 24–48 hours you didn't plan for, plus the appeal-writing you just read a 2,000-word guide on avoiding. A preflight check costs you five minutes. Run it before your next submission, not after your next rejection.
Frequently asked questions
How long does an App Store rejection appeal take?
Most Resolution Center replies land within 24–48 hours, since you're messaging the same reviewer who checked your build. If Apple needs to re-test your app, add another 1–2 days. Escalating to the App Review Board takes longer — often a week or more, since it's a separate review outside your original submission. If your appeal risks blowing a launch date, resubmitting a fixed build is usually faster than waiting on either channel.
Can you appeal an App Store rejection more than once?
Yes. You can reply in the Resolution Center as many times as needed, and each rejection carries its own thread. But reviewers lose patience with repeated appeals that don't add new information — per Guideline 1.1, they expect you to either provide evidence the rejection was a mistake or fix the actual issue. If your second appeal is just restating the first with different wording, resubmit a corrected build instead.
What's the difference between the Resolution Center and the App Review Board?
The Resolution Center is a message thread with the reviewer who rejected your build — use it to clarify a misunderstanding or provide missing context (a demo account, a metadata explanation). The App Review Board is a formal escalation for when you believe App Review misapplied a guideline, and a different team reviews your case. Always try the Resolution Center first — the Review Board is slower and expects you've already exhausted that path.
Will appealing a rejection hurt my chances on future submissions?
No — Apple has stated appeals don't count against you, and reviewers don't see your appeal history as a red flag. What does hurt you is submitting the same unfixed violation repeatedly, which reads as ignoring guidance rather than disputing a judgment call. A well-reasoned appeal citing the specific guideline is normal developer behavior, not a mark against your account.
Should I appeal or just fix the issue and resubmit?
Appeal only when you believe the reviewer misread your app — wrong guideline cited, a feature they missed, or a false crash report. If the rejection is accurate (missing privacy disclosure, broken IAP, incomplete metadata), fix it and resubmit — that's faster than arguing and gets you back in the review queue immediately. Appealing a valid rejection just burns a review cycle you didn't need to lose.