Rejection Handler

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

full access to all app features.

Audit 0.4.1 · source sha 7fd70e317e5c · 18 Oct 2026Report an issue or request a re-scan

• Publisherrshankras GitHub userOwner of the repository this skill is read from
• Source folderrshankras/claude-code-apple-skills/skills/app-store/rejection-handlerThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdict7fd70e317e5cA new audit runs when the source changes
• Repository statusNot archivedLast push 85 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its 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…

---
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]
last_verified: 2026-07-16
review_by: 2027-06-22
os_version: iOS 27 / macOS 27
---

# 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)

- [ ] 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

### Accurate Metadata (Guideline 2.3)

- [ ] App name matches what the app actually does
- [ ] Screenshots show the actual current app UI
- [ ] Description accurately represents functionality
- [ ] Category selection is appropriate
- [ ] No misleading claims ("best", "#1") without substantiation
- [ ] Age rating reflects actual content
- [ ] What's New text describes actual changes (not marketing copy)
- [ ] Keywords do not include competitor names or misleading terms

### Software Requirements (Guideline 2.5)

- [ ] App uses only public APIs (no private frameworks)
- [ ] No deprecated APIs that are marked for removal
- [ ] App works on the oldest supported iOS/macOS version claimed
- [ ] No remote code execution (no downloading and running code)
- [ ] IPv6 networking compatibility

### In-App Purchase Compliance (Guideline 3.1)

- [ ] All digital content/features use Apple's IAP (not Stripe, PayPal, etc.)
- [ ] Physical goods/services CAN use external payment
- [ ] Subscription terms are clear before purchase
- [ ] "Restore Purchases" button exists and works
- [ ] Subscription management is accessible within the app
- [ ] No language directing users to purchase outside the app
- [ ] Free trial terms are clearly stated

### Design Quality (Guideline 4.0)

- [ ] App uses native UI components (not a web wrapper for existing website)
- [ ] Supports current device screen sizes
- [ ] No empty states without guidance
- [ ] Error messages are user-friendly
- [ ] Loading states exist for async operations
- [ ] App provides meaningful functionality (not a glorified bookmark)

### Privacy Compliance (Guideline 5.1)

- [ ] Privacy policy URL is provided and accessible
- [ ] Privacy policy accurately describes data collection
- [ ] App Tracking Transparency prompt shown before tracking (if applicable)
- [ ] Privacy Nutrition Labels in App Store Connect match actual behavior
- [ ] Data minimization — only collect what you need
- [ ] User data deletion mechanism exists (if data is collected)
- [ ] Privacy manifest included (required for certain APIs, iOS 17+)

### Legal Requirements (Guideline 5.2)

- [ ] App complies with local laws in all territories where distributed
- [ ] Required age gates for restricted content
- [ ] Health/medical disclaimers if applicable
- [ ] Financial disclaimers if applicable

### App Review Notes (Submission)

- [ ] Demo account credentials provided (if login required)
- [ ] Special hardware instructions noted (if needed)
- [ ] Backend requirements explained (if features need server access)
- [ ] Explain non-obvious features or flows
- [ ] Mention any entitlements and why they're needed

## Rejection Handling Process

### Step 1: Read the Rejection Notice Carefully

When a user reports a rejection, gather:

1. **The exact guideline cited** (e.g., "Guideline 4.2 - Design - Minimum Functionality")
2. **The full rejection message text** (Apple provides specific details)
3. **Any screenshots or annotations** Apple included
4. **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, priva

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/rshankras/claude-code-apple-skills
git -C claude-code-apple-skills checkout 7fd70e317e5c

Works in

1. 2026-10-18
   ✓SAFE B 89 / 100

   first audit · source 7fd70e317e5c

Questions about Rejection Handler

• github.com/rshankras/claude-code-apple-skills/tree/main/skills/a — the audited source at commit 7fd70e317e5c and every finding aboveObserved · 18 Oct 2026

Spotted something wrong? Report a correction · Methodology