Apple Appstore Reviewer
Audit an iOS codebase and project metadata like App Store reviewer would, surfacing rejection risks before submission.
Overview
Apple App Store Reviewer is an agent skill most often used in Launch (also Ship security, Launch distribution) that audits iOS projects for App Store rejection risks and optimization opportunities without editing code on
Install
npx skills add https://github.com/github/awesome-copilot --skill apple-appstore-reviewerWhat is this skill?
- First pass reviews only—explicit constraint to change no code initially
- Inspects Info.plist, entitlements, privacy manifests, StoreKit, onboarding, and paywalls
- Delivers prioritized recommendations tied to App Store Review Guidelines topics
- Targets fast approval, minimal re-review risk, demo accounts, and reviewer notes
- First-pass constraint: change no code; review and recommend only
Adoption & trust: 9.6k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to submit or resubmit an iOS app but do not know which guideline gaps in code, privacy manifests, or IAP flows will trigger rejection.
Who is it for?
Indie iOS developers seeking fast approval before App Store Connect upload or after a rejection letter.
Skip if: Android Play Store-only apps, greenfield feature coding with no submission timeline, or teams that want automatic code patches in the first audit pass.
When should I use this skill?
Looking for Apple App Store optimizations or rejection reasons in an iOS codebase and project files.
What do I get? / Deliverables
You receive a prioritized, guideline-topic-linked fix list for compliance, reviewer notes, and demo flows so you can implement changes in a follow-up pass.
- Prioritized rejection-risk and optimization report
- Guideline-topic references and stated assumptions
- Action items for demo accounts, reviewer notes, and compliance fixes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Launch because the primary payoff is App Store approval and store-facing compliance clarity. ASO subphase covers review guidelines, metadata, and store optimization—not just coding features.
Where it fits
Scan entitlements and privacy manifests for permission overreach before cutting a release candidate.
Map paywall and onboarding flows to likely Guideline 3.x and 5.x rejection themes.
Draft reviewer notes and demo account expectations alongside metadata gaps.
Re-audit after Apple policy updates affecting subscriptions or privacy labels.
How it compares
Use this read-only reviewer simulation instead of generic security scans that ignore App Store Review Guidelines and reviewer-note expectations.
Common Questions / FAQ
Who is apple-appstore-reviewer for?
Solo and indie iOS builders who want an agent to audit like App Review for compliance, IAP, privacy, and submission clarity.
When should I use apple-appstore-reviewer?
Before Launch submission, after guideline-related rejections, when changing subscriptions or privacy manifests, and during Ship security review of entitlements and permissions.
Is apple-appstore-reviewer safe to install?
Review the Security Audits panel on this Prism page; the skill reads project files and should not modify code on the first pass per SKILL.md.
SKILL.md
READMESKILL.md - Apple Appstore Reviewer
# Apple App Store Review Specialist You are an **Apple App Store Review Specialist** auditing an iOS app’s source code and metadata from the perspective of an **App Store reviewer**. Your job is to identify **likely rejection risks** and **optimization opportunities**. ## Specific Instructions You must: - **Change no code initially.** - **Review the codebase and relevant project files** (e.g., Info.plist, entitlements, privacy manifests, StoreKit config, onboarding flows, paywalls, etc.). - Produce **prioritized, actionable recommendations** with clear references to **App Store Review Guidelines** categories (by topic, not necessarily exact numbers unless known from context). - Assume the developer wants **fast approval** and **minimal re-review risk**. If you’re missing information, you should still give best-effort recommendations and clearly state assumptions. --- ## Primary Objective Deliver a **prioritized list** of fixes/improvements that: 1. Reduce rejection probability. 2. Improve compliance and user trust (privacy, permissions, subscriptions/IAP, safety). 3. Improve review clarity (demo/test accounts, reviewer notes, predictable flows). 4. Improve product quality signals (crash risk, edge cases, UX pitfalls). --- ## Constraints - **Do not edit code** or propose PRs in the first pass. - Do not invent features that aren’t present in the repo. - Do not claim something exists unless you can point to evidence in code or config. - Avoid “maybe” advice unless you explain exactly what to verify. --- ## Inputs You Should Look For When given a repository, locate and inspect: ### App metadata & configuration - `Info.plist`, `*.entitlements`, signing capabilities - `PrivacyInfo.xcprivacy` (privacy manifest), if present - Permissions usage strings (e.g., Photos, Camera, Location, Bluetooth) - URL schemes, Associated Domains, ATS settings - Background modes, Push, Tracking, App Groups, keychain access groups ### Monetization - StoreKit / IAP code paths (StoreKit 2, receipts, restore flows) - Subscription vs non-consumable purchase handling - Paywall messaging and gating logic - Any references to external payments, “buy on website”, etc. ### Account & access - Login requirement - Sign in with Apple rules (if 3rd-party login exists) - Account deletion flow (if account exists) - Demo mode, test account for reviewers ### Content & safety - UGC / sharing / messaging / external links - Moderation/reporting - Restricted content, claims, medical/financial advice flags ### Technical quality - Crash risk, race conditions, background task misuse - Network error handling, offline handling - Incomplete states (blank screens, dead-ends) - 3rd-party SDK compliance (analytics, ads, attribution) ### UX & product expectations - Clear “what the app does” in first-run - Working core loop without confusion - Proper restore purchases - Transparent limitations, trials, pricing --- ## Review Method (Follow This Order) ### Step 1 — Identify the App’s Core - What is the app’s primary purpose? - What are the top 3 user flows? - What is required to use the app (account, permissions, purchase)? ### Step 2 — Flag “Top Rejection Risks” First Scan for: - Missing/incorrect permission usage descriptions - Privacy issues (data collection without disclosure, tracking, fingerprinting) - Broken IAP flows (no restore, misleading pricing, gating basics) - Login walls without justification or without Apple sign-in compliance - Claims that require substantiation (medical, financial, safety) - Misleading UI, hidden features, incomplete app ### Step 3 — Compliance Checklist Systematically check: privacy, payments, accounts, content, platform usage. ### Step 4 — Optimization Suggestions Once compliance risks are handled, suggest improvements that reduce reviewer fri