| name | rejection-handler |
| description | Handle App Store rejections, prepare submissions to avoid common rejection reasons, write Resolution Center responses, and navigate the appeal process. Use when user's app was rejected, is preparing for submission, or needs help with App Review. |
| allowed-tools | ["Read","Glob","Grep","AskUserQuestion"] |
App Store Rejection Handler
Guide developers through handling App Store rejections — from understanding why the rejection happened, to crafting effective responses, to escalating when appropriate.
When This Skill Activates
Use this skill when the user:
- Says their app was rejected by App Review
- Asks for help understanding a rejection notice
- Wants to prepare a submission to minimize rejection risk
- Needs help writing a response in Resolution Center
- Wants to appeal a rejection decision
- Asks about common App Store rejection reasons
- Mentions "App Review", "guideline violation", or "rejection"
- Wants a pre-submission audit for guideline compliance
Reference Files
Before handling a rejection, load:
| File | Purpose |
|---|
| common-rejections.md | Top 20 rejection reasons with fixes and response templates |
Pre-Submission Audit Checklist
Run through this before submitting to avoid the most common rejections. Each item maps to a specific App Store Review Guideline.
App Completeness (Guideline 2.1)
Accurate Metadata (Guideline 2.3)
Software Requirements (Guideline 2.5)
In-App Purchase Compliance (Guideline 3.1)
Design Quality (Guideline 4.0)
Privacy Compliance (Guideline 5.1)
Legal Requirements (Guideline 5.2)
App Review Notes (Submission)
Rejection Handling Process
Step 1: Read the Rejection Notice Carefully
When a user reports a rejection, gather:
- The exact guideline cited (e.g., "Guideline 4.2 - Design - Minimum Functionality")
- The full rejection message text (Apple provides specific details)
- Any screenshots or annotations Apple included
- Whether this is a first submission or re-submission
Ask via AskUserQuestion:
- "Can you paste the full rejection message from App Store Connect?"
- "Which guideline number was cited?"
- "Is this the first time this app has been submitted?"
- "Have you made changes since a previous rejection?"
Step 2: Identify the Rejection Category
Read common-rejections.md and match the cited guideline to the detailed breakdown. Determine:
- Is the rejection objectively correct? (crash, privacy violation, missing IAP)
- Is the rejection subjective? (minimum functionality, design quality)
- Is the rejection possibly in error? (reviewer misunderstood the app)
Step 3: Determine Response Strategy
Is the rejection objectively correct?
├── YES → Fix the issue and resubmit (Phase A)
└── NO → Did the reviewer misunderstand?
├── YES → Clarify with evidence (Phase B)
└── NO → Is it a subjective judgment call?
├── YES → Evaluate: fix or push back? (Phase C)
└── NO → Appeal (Phase D)
Phase A: Fix and Resubmit
For clear violations (crashes, missing privacy policy, private API usage):
- Fix the specific issue cited
- Test thoroughly on the device types Apple may have tested on
- In the Resolution Center reply, briefly state what was fixed
- Resubmit the binary
Response template (Fix and Resubmit):
Thank you for the review.
We've addressed the issue cited in Guideline [X.X]:
- [Specific change made]
- [How it was verified]
The updated build ([version] [build number]) has been submitted
for review.
Please let us know if you have any further questions.
Phase B: Clarify with Evidence
For rejections based on misunderstanding:
- Do NOT be defensive or argumentative
- Explain clearly what the app does and why it doesn't violate the guideline
- Provide screenshots, video, or step-by-step instructions
- Reference the specific guideline language and explain how you comply
Response template (Clarification):
Thank you for reviewing our app.
We'd like to provide additional context regarding Guideline [X.X].
[Clear explanation of how the feature/app works]
To demonstrate this:
1. [Step-by-step instructions to see the relevant feature]
2. [Step-by-step instructions continued]
[Optional: screenshot or video link]
We believe this addresses the concern raised. We're happy to
provide any additional information or make a call to discuss
further.
Phase C: Evaluate Subjective Rejections
For "minimum functionality" (4.2), "spam" (4.3), or "design" (4.0) rejections, decide:
When to fix (usually the better path):
- If you honestly agree the app could be more substantial
- If adding 2-3 features would make a meaningful difference
- If the reviewer's feedback, while harsh, has a point
- If you're early in development and can improve quickly
When to push back:
- If the app intentionally does one thing well (it's a focused tool, not incomplete)
- If similar apps exist on the App Store with less functionality
- If the reviewer appears to have missed core features
- If you have user testimonials or metrics showing the app delivers value
Response template (Pushing Back on Subjective Rejection):
Thank you for your feedback on our app.
We respectfully believe [App Name] provides meaningful
functionality as outlined in Guideline [X.X]:
1. [Core value proposition]
2. [Specific features that demonstrate depth]
3. [User benefit that differentiates from a simple website]
[App Name] is designed as a focused [type of app] that excels
at [specific purpose]. This intentional focus is a design
decision, not a limitation.
[Optional: "Similar apps like [X] and [Y] are available on the
App Store with comparable scope."]
We'd welcome the opportunity to discuss this further or
demonstrate the app's functionality in detail.
Phase D: Formal Appeal
If Resolution Center responses don't resolve the issue, escalate.
Appeal Escalation Path
Level 1: Resolution Center Reply (First Response)
- Reply directly in Resolution Center
- Be professional, concise, and evidence-based
- Include demo video if helpful
- Response time: 1-3 business days typically
Level 2: Request a Phone Call
If the Resolution Center reply doesn't resolve it:
- In Resolution Center, explicitly request: "We'd appreciate the opportunity to discuss this via phone call with the App Review team."
- Apple sometimes offers this for complex cases
- Prepare a clear, concise verbal explanation
- Have the app ready to demo live
- Response time: 3-7 business days
Level 3: App Review Board Appeal
If Level 1 and Level 2 fail:
- Submit a formal appeal at https://developer.apple.com/contact/app-store/
- Choose "App Review" and then "Appeal"
- This goes to a separate board, not the same reviewer
- One appeal per rejection — make it count
- Response time: 5-14 business days
Appeal writing tips:
- Lead with facts, not emotions
- Reference specific guideline language
- Explain why the rejection criteria don't apply or are being misapplied
- Mention comparable apps on the App Store (carefully — don't name-shame, but establish precedent)
- Keep it under 500 words
- Include a demo video link if the issue is about functionality
When to Change Approach vs. Push Back
Apple is usually right about:
- Crashes and bugs (fix them)
- Privacy violations (fix them)
- Missing IAP for digital goods (implement IAP)
- Misleading metadata (fix it)
- Private API usage (use public APIs)
Apple is sometimes wrong about:
- "Minimum functionality" for intentionally focused apps
- "Spam" for apps that serve distinct user segments
- "Could be a website" for apps with native features (widgets, notifications, offline)
- "Not enough native UI" for apps with legitimate custom interfaces
- Feature misunderstandings when reviewers don't find non-obvious functionality
Rule of thumb: If 3 people independently look at the rejection and all say "Apple has a point," fix the issue. If they all say "this seems wrong," push back with evidence.
Timeline Expectations
Typical Review Times
| Scenario | Expected Timeline |
|---|
| Initial submission | 1-3 days (24-48 hours typical) |
| Resubmission after rejection | 1-3 days |
| Expedited review request | Same day to 1 day |
| Resolution Center reply | 1-3 business days |
| Phone call request | 3-7 business days |
| App Review Board appeal | 5-14 business days |
When to Request Expedited Review
Apple allows expedited review requests for:
- Critical bug fixes for live apps
- Time-sensitive events (conference launch, holiday tie-in)
- Security patches
Do NOT request expedited review for:
- Initial submissions (no urgency justification)
- Feature updates (plan ahead)
- Rejected apps (use Resolution Center instead)
Seasonal Considerations
- WWDC (June): Slight delays as team focuses on new OS reviews
- September-October: iPhone launch creates surge, slightly longer times
- December holidays: Reduced staff, plan submissions before mid-December
- App Store freeze: Typically Dec 23-27, no new submissions processed
Resolution Center Best Practices
Tone
- Professional and respectful, always
- Concise — reviewers handle hundreds of cases
- Evidence-based — screenshots, videos, step-by-step instructions
- Solution-oriented — "here's what we changed" or "here's why this complies"
What to Include
- Reference the specific guideline number
- Quote the specific language from the rejection
- Provide clear evidence (screenshots, demo video, step-by-step reproduction)
- If you fixed something, state exactly what changed and in which build
- If you're clarifying, provide a walkthrough of the misunderstood feature
What to Avoid
- Emotional language ("this is unfair", "we worked so hard")
- Threats (legal action, press coverage, social media complaints)
- Comparing to competitor apps in a negative way
- Long, rambling responses (keep under 300 words for replies)
- Multiple replies in quick succession (wait for a response)
Response Length
- First reply: 100-200 words
- Clarification with evidence: 200-300 words
- Appeal: 300-500 words
Output Format
When handling a rejection, produce this assessment:
# Rejection Analysis: [App Name]
## Rejection Details
- **Guideline**: [X.X] - [Guideline Name]
- **Submission type**: Initial / Resubmission
- **Rejection message**: [Quoted text]
## Assessment
- **Category**: Objective violation / Subjective judgment / Possible error
- **Validity**: [Is Apple right? Partially right? Wrong?]
- **Recommended strategy**: Fix and resubmit / Clarify / Push back / Appeal
## Recommended Response
[Draft Resolution Center response]
## If Fixing: Action Items
1. [Specific change needed]
2. [Specific change needed]
3. [Verification step before resubmitting]
## If Appealing: Evidence to Prepare
- [Screenshot/video needed]
- [Comparable App Store precedent]
- [Guideline language to reference]
## Pre-Resubmission Checklist
- [ ] Issue addressed
- [ ] Tested on [device types]
- [ ] App Review notes updated
- [ ] Demo account credentials current
- [ ] Resolution Center response sent
Related Skills
- common-rejections.md — Detailed breakdown of top 20 rejection reasons with fix guides
- Related:
release-review — Pre-release audit that catches rejection-causing issues
- Related:
security/privacy-manifests — Privacy manifest compliance
- Related:
app-store/app-description-writer — Metadata accuracy (prevents Guideline 2.3 rejections)
- Related:
monetization — IAP compliance guidance (prevents Guideline 3.1 rejections)
