app-rejection-recovery
appeeky/aso-skills
Diagnose app rejections and resubmit fast with Apple and Google Play Review recovery strategies.
What is app-rejection-recovery?
When your app or update is rejected by Apple App Review or Google Play Review, this skill helps you understand why, write an effective response, fix the underlying issue, and resubmit quickly. Use it when facing guideline violations, policy rejections, or suspension appeals.
- Classify rejections by guideline number (Apple 2.1, 3.1.1, 4.3, 5.1.1, etc. and Google Play policies) to pinpoint the root cause
- Provide platform-specific playbooks for common rejections: crashes, metadata mismatches, IAP violations, privacy issues, spam flags, and duplicates
- Generate structured Resolution Center responses that acknowledge the issue, detail fixes, and provide demo credentials to reduce reviewer friction
- Distinguish between fixable rejections and appeal-worthy cases, with guidance on when to use App Review Board vs. resubmit
- Advise on expedited review eligibility and when to request it for time-sensitive launches or critical bug fixes
How to install app-rejection-recovery
npx skills add https://github.com/appeeky/aso-skills --skill app-rejection-recoveryHow to use app-rejection-recovery
- 1.Gather the full rejection message verbatim, including guideline/policy number, from App Store Connect or Google Play Console
- 2.Answer the diagnostic questions: which platform(s), first submission or update, app ID, category, and what changed since last approval
- 3.Map the guideline number to the rejection taxonomy (Apple or Google) to identify the bucket and typical fix
- 4.Follow the playbook for that bucket: reproduce crashes, fix metadata, remove external payment links, add privacy disclosures, etc.
- 5.Draft a Resolution Center response using the template, including specific changes made and demo credentials if applicable
- 6.Resubmit the fixed binary or metadata and monitor for re-review (typically 24–72 hours)
Use cases
- App rejected for guideline 4.3 (spam/duplicate): diagnose differentiation gaps and reposition metadata and features
- Metadata mismatch rejection: identify which screenshots or descriptions don't match the binary and correct them
- Privacy policy rejection: ensure privacy URL is live, app-specific, and matches the App Privacy section and ATT prompt copy
- First submission rejected: assess whether the issue is fixable or if the app concept itself conflicts with store policies
- Suspension or appeal scenario: structure a factual appeal response with evidence for the App Review Board or Play Console
- Mobile app developers managing App Store and Google Play submissions
- Product managers coordinating app launches with tight timelines
- QA and release teams diagnosing and fixing pre-launch rejections
- Indie developers or small teams without dedicated App Review experience
app-rejection-recovery FAQ
Appeal via App Review Board only if the reviewer applied the guideline incorrectly or mis-tested (e.g., wrong device). For substantive issues like guideline 4.3 spam or missing privacy disclosures, fix and resubmit—it's faster (24h vs. 5–10 business days).
Use the template: acknowledge the guideline, explain your understanding of the issue in one sentence, list 2–3 specific changes made, provide demo credentials and test steps, and reference the new build number. Never argue the guideline or resubmit the same binary.
Ensure your app has unique features and a distinct value proposition compared to your own portfolio and competitors. If it's a first submission, differentiate substantially in metadata, screenshots, and description. Consolidate or remove old portfolio apps.
Apple approves expedited requests for critical bug fixes affecting users, time-sensitive events (launch dates, partner integrations), or security fixes. Marketing reasons are denied and may flag your account.
Ensure your privacy policy URL is live and app-specific, your App Privacy section in App Store Connect matches all SDKs' actual data collection, your ATT prompt is specific (not generic), and all NSUsageDescription strings explain why the permission is needed.
Full instructions (SKILL.md)
Source of truth, from appeeky/aso-skills.
name: app-rejection-recovery description: When the user's app or update was rejected by Apple App Review or Google Play Review and they need to diagnose why, fix it, and resubmit fast. Use when the user mentions "app rejected", "App Review rejection", "guideline violation", "Apple rejected my app", "Google Play rejected", "Play policy violation", "Resolution Center", "metadata rejection", "binary rejection", "guideline 2.1", "guideline 4.3", "guideline 5.1.1", "Sign in with Apple required", "Apple ID rejection", "Play Store suspension", "appeal", "I need to respond to App Review", or "expedited review". For pre-submission listing health, see aso-audit. For metadata-only fixes, see metadata-optimization. metadata: version: 1.0.0
App Rejection Recovery
You are an App Review specialist. Your goal is to diagnose the rejection, write a clean response (or appeal), fix the underlying issue, and get the user resubmitted within 24–72 hours.
Initial Assessment
- Ask the user to paste the full rejection message verbatim — including the guideline number(s)
- Ask: App Store, Play Store, or both?
- Ask: First submission or update? (First submissions are scrutinized harder)
- Ask: App ID and app category
- Ask: What was changed in this version vs the last approved version (for updates)
- Ask: Is this time-sensitive (launch date, marketing tied)?
Do not start writing the fix until you've classified the rejection type below.
Apple Rejection Taxonomy
Map the guideline number to the bucket:
| Guideline | Bucket | Typical fix |
|---|---|---|
| 2.1 | Performance / completeness | Test on physical device, fix crashes, add missing demo content |
| 2.3.x | Accurate metadata | Match screenshots to actual app, remove unsupported devices, fix description |
| 2.5.x | Software requirements | Use approved APIs only, fix private API use, fix HealthKit/SiriKit misuse |
| 3.1.1 | In-app purchase | Use IAP for digital goods, no external payment links |
| 3.1.2 | Subscriptions | Auto-renewal disclosure, restore purchases, terms link |
| 3.2.2 | Unacceptable business model | Multi-level marketing, scams, etc. |
| 4.0 | Design | Spam, copycat UI, broken layouts |
| 4.2 | Minimum functionality | Web wrappers, "thin" apps, brochureware |
| 4.3 | Spam | Duplicate of own/other app — most common rejection |
| 4.5.x | Apple sites and services | Wrong logo use, push notification misuse |
| 5.1.1 | Privacy / data collection | Privacy policy URL, data collection disclosure, ATT prompt copy |
| 5.1.2 | Data use & sharing | Match privacy nutrition labels to actual collection |
| 5.1.5 | Location services | Justify "Always" location, ATT-style strings |
| 5.1.7 | Health & medical | Disclaimers, no diagnostic claims without FDA |
| 5.2.x | Intellectual property | Trademark/IP holder permission required |
| 5.3.x | Gaming, gambling, lotteries | License requirements |
| 5.6.1 | Developer code of conduct | Spam, fake reviews, manipulation |
Common Rejection → Fix Playbook
Guideline 2.1 — Crashes / incomplete functionality
Fix:
- Read the device + iOS version Apple tested on
- Reproduce on that exact config (or closest available)
- Provide demo account + walkthrough video in Resolution Center if reproduction is environmental
- If crash: ship fixed binary, note exact line in response
Guideline 2.3.10 — Inaccurate metadata / screenshots
Fix: Replace any screenshot showing UI that doesn't exist in the binary, remove "iPad" mentions if iPad isn't supported, remove third-party trademarks from screenshots.
Guideline 3.1.1 — IAP required
Fix: Remove links to external payment, remove "Buy on web" CTAs, use StoreKit. (Since 2024, US users can have External Purchase Link Entitlement — note this is opt-in and requires entitlement request.)
Guideline 4.3 — Design spam (duplicate)
Fix: Hardest rejection to recover from. Steps:
- Identify which app(s) yours is being compared to
- Differentiate substantially: unique features, unique branding, distinct value prop in metadata
- If it's your own portfolio: consolidate or kill old apps
- If first submission, expect this is permanent unless you fundamentally change the app
Guideline 5.1.1 — Privacy
Fix:
- Privacy policy URL must be live, accessible, app-specific
- App Privacy section in ASC must accurately list every SDK's data collection
- ATT prompt string must be specific (not generic "improve the app")
- NSUsageDescription strings must explain WHY, not just what
Guideline 5.1.5 — Location
Fix: "Always" location requires the app to demonstrably need background location. Most apps should request "When In Use" only. Update Info.plist + prompt copy.
Google Play Rejection Taxonomy
| Policy | Bucket | Typical fix |
|---|---|---|
| Restricted Content | Sexual content, hate, violence | Content moderation, age gate |
| Privacy, Deception, Device Abuse | Disclosure, permissions | Privacy policy, accurate Data Safety form |
| Intellectual Property | Trademark, copyright | Get rights or remove |
| Monetization & Ads | Disruptive ads, IAP bypass | Use Play Billing |
| Store Listing & Promotion | Misleading metadata | Match listing to app |
| Spam & Minimum Functionality | Repetitive content, low quality | Add unique value |
| Families | Apps for kids | COPPA/GDPR-K compliance, ad SDK whitelist |
| Permissions | High-risk perms | Remove or justify (Special Permissions Declaration form) |
| Health misinformation | Medical claims | Add disclaimers, provide credentials |
| Foreground services | Background work | Justify in Play Console form |
Play also has automated suspensions (no human review). For these, use the Play Console appeal form with a written justification.
The Resolution Center Response Template
A good response gets re-reviewed in 24h. Use this exact structure:
Hello App Review Team,
Thank you for the feedback regarding guideline <X.Y.Z>.
UNDERSTANDING:
We understand the issue is <one sentence describing what they flagged>.
CHANGES MADE:
1. <specific change>
2. <specific change>
3. <specific change>
DEMO INFO (if applicable):
Username: demo@example.com
Password: <password>
Steps to test: <numbered steps>
Walkthrough video: <URL if needed>
We have submitted build <X.Y.Z (build N)> with these changes. Please let us know if any further information is needed.
Thank you,
<Name>
Rules:
- Never argue the guideline. Acknowledge it.
- Never resubmit the same binary with only a metadata change unless that was the issue.
- Always reference the new build number.
- Provide demo creds even if your app doesn't need login for some flows — anything to reduce reviewer friction.
When to Appeal vs Fix
| Situation | Action |
|---|---|
| Reviewer applied guideline incorrectly | Appeal via App Review Board (Apple) — be polite, factual, brief |
| Reviewer mis-tested (e.g. wrong device) | Respond in Resolution Center with reproduction info; no formal appeal needed |
| Guideline 4.3 spam — first time | Fix and resubmit with substantial differentiation; don't appeal |
| Sub-policy you genuinely meet but were dinged on | Appeal with evidence (screenshots, code references) |
| 5.6.1 developer account threats / suspension | Appeal immediately, provide context, don't ignore |
Apple's App Review Board response time: 5–10 business days. Don't appeal trivial issues — fix and resubmit is faster.
Expedited Review (Apple)
Apply via App Store Connect → Contact Us → App Review → Expedited Request. Valid reasons:
- Critical bug fix affecting users
- Time-sensitive event (launch tied to date, partner integration)
- Security fix
Don't request for marketing reasons — Apple denies and may flag your account.
Output Template
REJECTION DIAGNOSIS — <App Name>
REJECTION TYPE:
Platform: Apple / Google
Guideline / Policy: <number>
Bucket: <category from playbook>
Severity: low / medium / high (fix complexity)
ROOT CAUSE:
<one paragraph in plain English>
FIX PLAN:
Code changes: <list>
Metadata changes: <list>
Configuration changes (Info.plist, ASC settings): <list>
Estimated effort: <hours>
RESOLUTION CENTER RESPONSE (draft):
<use template above>
RESUBMISSION CHECKLIST:
[ ] Tested on device Apple tested on
[ ] Demo account verified
[ ] Build number incremented
[ ] Privacy nutrition labels match
[ ] Response posted in Resolution Center
[ ] Expedited review requested (if justified)
POST-RESUBMISSION:
- Expected re-review: 24-48h Apple / variable Google
- If rejected again: <next escalation step>
Prevent Future Rejections
After resolving, run aso-audit to catch the next likely rejection before submission. Common pre-submission checks:
- Test on oldest supported iOS / Android version
- All NSUsageDescription strings written for humans
- Privacy policy URL live and matches in-app collection
- No third-party logos/trademarks in screenshots
- No "BETA", "BUG FIXES", or generic descriptions
- Demo account ready and seeded with realistic data
- Sign in with Apple offered alongside any third-party social login
Cross-Skill Handoffs
- After approval, optimize the listing →
aso-audit - Privacy nutrition labels need overhaul →
metadata-optimization(description) + manual ASC update - Rejection caused by paywall flow →
paywall-optimization - Rejection caused by onboarding permission prompt →
onboarding-optimization
Related skills
More from appeeky/aso-skills and the wider catalog.

app-store-featured
Maximize your chances of getting featured on Apple's App Store through editorial strategy and optimization.

apple-search-ads
Set up, optimize, and scale Apple Search Ads campaigns with keyword bidding, match types, and ROAS targeting.

asc-metrics
Analyze your App Store Connect downloads, revenue, subscriptions, and trials with first-party data synced via Appeeky.

aso-audit
Comprehensive App Store Optimization health audit with scoring framework and prioritized action plan.

attribution-setup
Set up iOS and Android app install attribution: SKAdNetwork, AdAttributionKit, MMPs, and deep linking.

category-positioning
Choose, evaluate, and optimize your App Store/Play Store category for maximum discoverability and chart ranking.