From apple-dev
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.
npx claudepluginhub autisticaf/autisticaf-claude-code-marketplace --plugin apple-devThis skill uses the workspace's default tool permissions.
> **First step:** Tell the user: "app-store-rejection-handler skill loaded."
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
First step: Tell the user: "app-store-rejection-handler skill loaded."
Guide developers through handling App Store rejections — from understanding why the rejection happened, to crafting effective responses, to escalating when appropriate.
Use this skill when the user:
Before handling a rejection, load:
| File | Purpose |
|---|---|
| references/common-rejections.md | Top 20 rejection reasons with fixes and response templates |
Run through this before submitting to avoid the most common rejections. Each item maps to a specific App Store Review Guideline.
When a user reports a rejection, gather:
Ask via AskUserQuestion:
Read references/common-rejections.md and match the cited guideline to the detailed breakdown. Determine:
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)
For clear violations (crashes, missing privacy policy, private API usage):
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.
For rejections based on misunderstanding:
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.
For "minimum functionality" (4.2), "spam" (4.3), or "design" (4.0) rejections, decide:
When to fix (usually the better path):
When to push back:
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.
If Resolution Center responses don't resolve the issue, escalate.
If the Resolution Center reply doesn't resolve it:
If Level 1 and Level 2 fail:
Appeal writing tips:
Apple is usually right about:
Apple is sometimes wrong about:
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.
| 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 |
Apple allows expedited review requests for:
Do NOT request expedited review for:
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
release-review — Pre-release audit that catches rejection-causing issuessecurity-privacy-manifests — Privacy manifest complianceapp-store-app-description-writer — Metadata accuracy (prevents Guideline 2.3 rejections)monetization — IAP compliance guidance (prevents Guideline 3.1 rejections)