/app-review-max

name: app-review-max
description: "Pass Apple App Review the first time and recover fast when rejected. USE THIS SKILL whenever the user is submitting to the App Store, preparing a submission, asks 'will this get rejected', mentions App Review, a rejection, Resolution Center, an appeal, or any guideline number (2.1, 2.3, 3.1.1, 4.3, 5.1.x, etc.); whenever they set up TestFlight external testing / Beta App Review; whenever they want pre-submission checks, QC, demo accounts, reviewer notes, metadata or screenshot review; and whenever they ask IAP/paywall/subscription questions framed as compliance ('is this allowed', 'can I link to my website for payment'). Covers rejection playbooks, monetization compliance (US anti-steering + EU DMA state as of mid-2026), and an archive-to-approval checklist. Defer privacy manifests, GDPR, and legal document drafting to apple-legal-max; defer versioning, phased release, and release automation to apple-release-ops."

App Review Max — Pass Review, Recover From Rejection

You own one outcome: the app gets **approved**. Audit like a reviewer, fix like a developer, and write reviewer-facing text like someone who wants a 24-hour turnaround.

Scope boundaries: privacy manifests, nutrition labels, GDPR/CCPA, and legal documents belong to `apple-legal-max`. Build numbers, phased release, and release automation belong to `apple-release-ops`. This skill covers everything App Review and QC: guideline compliance, pre-submission checks, rejection recovery, and reviewer communication.

How App Review Actually Works

Know the machine before you feed it:

1. **Upload-time automated checks.** The moment a build hits App Store Connect, automated analysis scans for private API usage, missing usage-description strings, malformed Info.plist entries, missing privacy manifest declarations, and invalid entitlements. These produce ITMS errors/warnings by email — fix them before human review ever starts. 2. **Human review.** A reviewer installs your build on a physical device (recent iOS, typically from a California/US network — plan geofencing and allowlists accordingly), reads your metadata, and exercises the app for minutes, not hours. They follow your App Review notes if you wrote any; they improvise if you didn't. 3. **Timeline.** Apple states 90% of submissions are reviewed within 24 hours. Budget 24–48h per attempt, and assume at least one rejection cycle for first submissions — plan launch dates with a week of buffer. 4. **What reviewers see.** Your binary, all metadata (name, subtitle, description, keywords, screenshots, previews), your privacy labels, the age-rating questionnaire, IAP products submitted with the build, and your App Review notes. They do NOT see your source code, your roadmap, or your intentions. If a feature is invisible or gated, it does not exist unless your notes make it exist. 5. **Rejection anatomy.** Rejections arrive in App Store Connect (Resolution Center thread) citing specific guideline numbers, often with screenshots of the offending screen. Two flavors: **binary rejected** (fix requires a new build) and **metadata rejected** (fix the listing text/screenshots and resubmit the same build — much faster). 6. **Scale context.** Apple reviews millions of submissions a year and rejects roughly a quarter of them. Rejection is routine process, not catastrophe. Treat the first rejection as a data point, not a verdict.

Top Rejection Guidelines, Ranked by Frequency

Attack these in order — they cover the overwhelming majority of rejections. Deep dives with fixes and resubmission wording: [references/rejection-playbook.md](references/rejection-playbook.md).

| Rank | Guideline | What it is | One-line avoidance | |---|---|---|---| | 1 | **2.1 App Completeness** (~40% of all rejections) | Crashes, bugs, placeholder content, broken links, reviewer can't get past login | Test the exact archived build on a physical device + IPv6, and put a working demo account in App Review notes. | | 2 | **2.3.x Accurate Metadata** | Screenshots not matching the app, misleading descriptions, hidden features, irrelevant keywords, prices in metadata | Every screenshot must be real UI from this build; describe only what this version does, in this version's UI. | | 3 | **3.1.x Payments** | Digital goods sold outside IAP, missing restore, unclear subscription terms, non-compliant external links | Digital content/features go through IAP unless a 3.1.3 exception or your storefront's current external-link rules apply — verify region rules in [references/monetization-compliance.md](references/monetization-compliance.md). | | 4 | **4.3 Spam / Design Minimum + 4.2 Minimum Functionality** | Template/copycat apps, thin wrappers around a website, duplicative submissions | Ship at least one capability a mobile-optimized website can't do, and never resubmit near-identical apps under new bundle IDs. | | 5 | **5.1.x Privacy** | Missing/inaccessible privacy policy, vague permission strings, data collection without consent, undisclosed third-party AI sharing, no in-app account deletion | Every permission string names the feature it powers; privacy policy URL loads; account creation implies in-app account deletion; disclose and get consent before sending personal data to any third party, including AI APIs (5.1.2(i), tightened Nov 2025). | | 6 | **4.0 Design** | Broken layouts, non-native UX, iPhone app unusable on iPad, ignoring safe areas | Run the release build on smallest and largest supported devices; fix anything that looks broken in 10 seconds of use. |

Pre-Submission QC Checklist (Fast Pass)

Run this before every submission. Full ordered archive-to-approval list: [references/submission-checklist.md](references/submission-checklist.md).

• [ ] **Demo account**: working credentials in App Review notes; account pre-populated with realistic data; not expired; 2FA disabled or one-time codes provided. If login uses phone/SMS only, provide a test number that accepts a fixed