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.
9k tokens
context cost
the whole folder, loaded on every use
2
files
instructions only
0
copies elsewhere
how many repositories repackaged it
585
stars on the repo
on the repository, not the skill itself
Install
one command, takes just this skill from the repository
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)
[ ] App launches without crashing on all supported devices
[ ] All features described in metadata are functional
[ ] No placeholder content (lorem ipsum, test data, TODO screens)
[ ] No broken links or dead-end navigation
[ ] All buttons and interactive elements work
[ ] Demo/test accounts provided in App Review notes if login is required
[ ] Beta or test labels removed from UI and metadata
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) |