# App Store Review > > - **Type:** Skill - **Install:** `agentstack add skill-justinperea-app-store-review-skill-app-store-review-skill` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [JustinPerea](https://agentstack.voostack.com/s/justinperea) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [JustinPerea](https://github.com/JustinPerea) - **Source:** https://github.com/JustinPerea/app-store-review-skill ## Install ```sh agentstack add skill-justinperea-app-store-review-skill-app-store-review-skill ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [JustinPerea](https://github.com/JustinPerea) - **Source:** [JustinPerea/app-store-review-skill](https://github.com/JustinPerea/app-store-review-skill) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-justinperea-app-store-review-skill-app-store-review-skill - Seller: https://agentstack.voostack.com/s/justinperea - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.