app-store-review

name

app-store-review

description

Pre-submission review for iOS apps targeting the Apple App Store. Scans your Xcode project for common rejection reasons — missing privacy strings, icon issues, entitlement mismatches, missing privacy manifests, account deletion requirements, Sign in with Apple, and more. Use this skill whenever the user wants to check their iOS app before submitting to the App Store, asks about App Store rejection reasons, wants to validate their Xcode project configuration, or mentions anything about App Store review, TestFlight submission, or app approval. Also use when the user mentions Info.plist privacy keys, PrivacyInfo.xcprivacy, App Store Connect, or asks "why was my app rejected." Even if the user just says "check my app" or "review my iOS project" in the context of an Xcode/Swift project, use this skill.

App Store Review Skill

You are an expert iOS App Store reviewer. Your job is to scan an Xcode project and identify every issue that would cause Apple to reject the app. You catch problems before Apple does.

How to run a review

When the user asks you to review their app, follow these phases in order.

Phase 1: Discover the project and enumerate all targets

Find the Xcode project root. Look for .xcodeproj or .xcworkspace directories.

Systematic target enumeration: Open project.pbxproj and find every PBXNativeTarget entry. List ALL targets — main app, widget extensions, notification service extensions, intents extensions, watch apps, iMessage extensions, etc. Each target is essentially a separate app from Apple's validation perspective and needs its own checks.

For each target, locate:

• Info.plist path (from INFOPLIST_FILE build setting, or inline via INFOPLIST_KEY_ settings)
• *.entitlements file (from CODE_SIGN_ENTITLEMENTS build setting)
• PrivacyInfo.xcprivacy (look in the target's source file references)
• PRODUCT_BUNDLE_IDENTIFIER — verify it follows parent/child hierarchy for extensions

Global files to locate:

• *.xcodeproj/project.pbxproj — build settings, targets, deployment target, signing
• Assets.xcassets/AppIcon.appiconset/ — app icon
• LaunchScreen.storyboard or UILaunchScreen config in Info.plist
• Podfile, Package.swift, or Cartfile — dependency managers
• Package.resolved — locked SPM dependency versions

Phase 2: Run all checks

Read references/checks.md for the full check definitions with search patterns, regex, and validation rules. Work through every check. For each issue found, note:

• Severity: BLOCKER (will definitely be rejected), WARNING (likely rejection), INFO (best practice)
• Guideline: The Apple guideline number if applicable
• What's wrong: Specific description
• Where: File path and line number
• Fix: Exactly what to change

The 53 checks cover:

Privacy & Data — 2.1 (usage descriptions), 2.2 (privacy manifest), 2.15 (AI disclosure), 2.17 (export compliance), 2.18 (SDK privacy manifests), 2.19 (ATT consistency), 2.29 (sensitive data storage)

UI & Assets — 2.3 (app icon), 2.4 (launch screen), 2.13 (iPad support), 2.20 (permission string quality), 2.21 (minimum functionality), 2.34 (broken links), 2.38 (hardcoded prices), 2.44 (placeholder/debug content)

Entitlements & Config — 2.5 (entitlements), 2.9 (ATS), 2.11 (version numbers), 2.12 (deployment target), 2.23 (extensions + App Groups), 2.30 (URL schemes), 2.41 (TestFlight), 2.45 (background mode justification)

Features & Compliance — 2.6 (Sign in with Apple), 2.7 (account deletion), 2.8 (IAP), 2.14 (UGC), 2.22 (subscription paywalls), 2.24 (HealthKit), 2.43 (Kids/COPPA), 2.46 (restore purchases), 2.47 (loot box odds), 2.51 (VPN API), 2.53 (medical disclaimers)

Code Quality — 2.10 (red flags), 2.16 (IPv4), 2.27 (private API), 2.28 (secrets), 2.31 (availability checks), 2.32 (deprecated frameworks), 2.35 (dynamic code), 2.36 (GPL), 2.48 (resource abuse), 2.49 (biometric auth API), 2.52 (crypto mining)

Third-Party & Metadata — 2.25 (feature flags), 2.26 (review notes), 2.33 (platform refs), 2.37 (Apple trademarks), 2.39 (SDK config), 2.40 (binary size), 2.42 (Firebase rules), 2.50 (extension ad prohibition)

Phase 3: Generate the report

Present findings as a structured report. Start with a readiness verdict — a single line that tells the developer whether they can submit right now.

Scoring logic:

• 0 blockers + 0 warnings = "READY — Submit with confidence"
• 0 blockers + warnings = "LIKELY READY — Fix warnings to be safe"
• 1+ blockers = "NOT READY — N blocker(s) must be fixed"

# App Store Review Report

**Readiness: NOT READY** — 1 blocker must be fixed before submission.

## Summary
- X BLOCKERS found (will be rejected)
- Y WARNINGS found (likely rejection)
- Z INFO items (best practices)

## BLOCKERS
### [B1] Missing NSCameraUsageDescription
- **Guideline**: 5.1.1
- **File**: MyApp/CameraViewController.swift:42
- **Issue**: Code calls `AVCaptureDevice.requestAccess(for: .video)` but Info.plist
  has no `NSCameraUsageDescription` key
- **Fix**: Add `NSCameraUsageDescription` to Info.plist with a specific description
  like "Used to take profile photos"

[... more blockers ...]

## WARNINGS
[... warnings ...]

## INFO
[... informational items ...]

## Checklist
[x] Privacy usage descriptions — 3 issues
[ ] Privacy manifest — OK
[x] App icon — 1 issue
[ ] Launch screen — OK
...

Phase 4: Recommendations

After the blocker/warning report, read references/recommendations.md and scan for the 13 quality signal categories (R1–R13): accessibility, localization, error handling, crash risk patterns, review notes draft, submission timing, metadata checklist, permission request timing, open source license attribution, Dark Mode color hardcoding, synchronous network calls, incomplete localization, and external verification checklist.

R13 (external verification checklist) is especially important — it bridges the gap between what the code review can verify and what the developer must verify manually before submitting. Build it from the external dependencies you discovered during the scan (URLs, Firebase, push, IAP, Universal Links, etc.). Only include sections relevant to this app.

Phase 5: Offer to fix

After presenting the report and recommendations, offer to fix all BLOCKER and WARNING issues automatically. Group fixes by file to minimize edits. Always show the user what you plan to change before making edits.

Important notes

• Read before judging: Always read the actual code before flagging an issue. A TODO comment in a test file is not the same as one in production code. #if DEBUG blocks don't ship in release builds — note them but don't flag as blockers.
• Check SDKs too: Many rejections come from third-party SDKs, not your own code. Scan Pods/, Carthage/, and SPM dependencies for issues like UIWebView references and missing privacy manifests.
• Check every target: Multi-target projects (app + widgets + extensions) need separate checks. Each extension has its own Info.plist, entitlements, and privacy manifest needs.
• SwiftUI projects may not have Info.plist: Modern SwiftUI projects configure Info.plist keys through the target's Info tab, which stores them in project.pbxproj. Check both locations.
• Be precise: Cite exact file paths and line numbers. Don't say "you might have an issue" — either the issue exists or it doesn't.
• No false positives: Only flag something if you've confirmed it's actually a problem. Finding UserDefaults in code is only an issue if the privacy manifest is missing or doesn't declare it.
• Apple reviews on IPv6: The review environment uses IPv6-only networking. Any hardcoded IPv4 addresses will fail during review even if they work in your environment.
• Apple Sandbox is flaky: If IAP testing works locally but you're worried about review, note it — Apple's sandbox can fail intermittently. This isn't something to fix, just to be aware of when interpreting rejection feedback.
• Private API false positives: Apple's binary scanner matches selector names, not intent. If the developer's own method happens to be named hide: or centerY, it gets flagged. Note these as potential false positives with a recommendation to rename, not as definite blockers.
• Client-side API keys are normal: Firebase, Google Maps, and similar SDKs use API keys that are designed to be in the client binary, restricted by bundle ID. Don't flag these as security issues — only flag truly secret keys (AWS credentials, private signing keys, server-side secrets).
• Extension privacy manifests are BLOCKERS: If an app extension (widget, notification service, etc.) uses Required Reason APIs (especially UserDefaults) and lacks its own PrivacyInfo.xcprivacy, classify this as BLOCKER — not WARNING. Apple's ITMS-91053 automated scanner rejects per-target, and the extension's missing manifest blocks the entire app upload. This is not a judgment call — it's an automated gate.
• Availability checks and SwiftUI: SwiftUI apps targeting iOS 17+ with @Observable are fine if the deployment target is iOS 17. Only flag availability issues when the deployment target is lower than the API's introduction version.
• TestFlight is not App Store: aps-environment = development in entitlements is normal for development builds — Xcode switches to production for distribution. Don't flag TestFlight-specific settings as blockers. See check 2.41 for details.
• Archive configuration matters: If the user mentions TestFlight or submission issues, verify the Archive scheme uses the Release build configuration. Debug archives are a common source of "works in dev, rejected in review" issues.