| name | app-store-review |
| description | Evaluates code against Apple's App Store Review Guidelines. Use this skill when reviewing iOS, macOS, tvOS, watchOS, or visionOS app code (Swift, Objective-C, React Native, or Expo) to identify potential App Store rejection issues before submission. Triggers on tasks involving app review preparation, compliance checking, or App Store submission readiness. |
| license | MIT |
| metadata | {"author":"safaiyeh","version":"1.3.0"} |
App Store Review Guidelines Checker
Comprehensive guide for evaluating iOS, macOS, tvOS, watchOS, and visionOS app code against Apple's App Store Review Guidelines. This skill covers EVERY guideline point to identify potential rejection issues before submission.
Supports: Swift, Objective-C, React Native, and Expo apps
Guidelines current through: Apple's June 8, 2026 App Review Guidelines update (verified still current as of August 29, 2026). Also incorporates post-June policy announcements: social media age-rating questions (mandatory September 2026), Republic of Korea age rating changes (August/October 2026), and Brazil/EU alternative payment and distribution terms.
When to Apply
Use this skill when:
- Preparing an app for App Store submission
- Reviewing code for compliance issues
- Implementing features that may trigger review concerns
- Auditing existing apps for guideline violations
- Building features involving payments, user data, or sensitive content
Guideline Sections
Read individual rule files for detailed explanations, checklists, and code examples:
| Section | File | Key Topics |
|---|
| 1. Safety | rules/1-safety.md | Objectionable content, UGC moderation, Kids Category, physical harm, data security |
| 2. Performance | rules/2-performance.md | App completeness, metadata accuracy, hardware compatibility, software requirements |
| 3. Business | rules/3-business.md | In-app purchase, subscriptions, cryptocurrencies, other business models |
| 4. Design | rules/4-design.md | Copycats, minimum functionality, spam, extensions, Apple services, login |
| 5. Legal | rules/5-legal.md | Privacy, data collection, intellectual property, gambling, VPN, MDM, developer code of conduct |
Risk Levels by Category
| Risk Level | Category | Section | Common Rejection Reasons |
|---|
| CRITICAL | Privacy & Data | 5.1 | Missing privacy policy, unauthorized data collection |
| CRITICAL | Payments | 3.1 | Bypassing in-app purchase, unclear pricing |
| HIGH | Safety | 1.x | Objectionable content, inadequate UGC moderation |
| HIGH | Performance | 2.x | Crashes, incomplete features, deprecated APIs |
| MEDIUM | Design | 4.x | Copycat apps, minimum functionality issues |
| MEDIUM | Legal | 5.x | IP violations, gambling without license |
Quick Reference: High-Risk Rejection Patterns
Critical Issues (Immediate Rejection)
Swift:
let selector = NSSelectorFromString("_privateMethod")
let apiKey = "sk_live_xxxxx"
func purchaseDigitalContent() {
openStripeCheckout()
}
React Native / Expo:
const API_KEY = 'sk_live_xxxxx';
Linking.openURL('https://stripe.com/checkout');
eval(downloadedCode);
High-Risk Issues
Swift:
import FacebookAds
func createAccount() { }
React Native / Expo:
import analytics from '@react-native-firebase/analytics';
analytics().logEvent('event');
Linking.openURL('https://example.com/delete');
<GoogleSigninButton />
showCustomAlert('Rate us 5 stars!');
Medium-Risk Issues
"This app needs camera access"
const App = () => <WebView source={{ uri: 'https://site.com' }} />;
const text = "Also available on Android";
console.log('debug');
Pre-Submission Checklist
Privacy (Section 5.1)
Payments (Section 3.1)
Safety (Section 1.x)
Performance (Section 2.x)
Design (Section 4.x)
Legal (Section 5.x)
Reporting Skill Issues (Feedback)
This skill improves through user reports. If during a session you observe that this skill failed the user, offer — once per session — to report it to the maintainer.
Offer feedback when you observe any of these. Classify with the category name — it goes in the issue title as [Feedback] <category>: <short description>.
Accuracy
- False positive — the skill flagged code that is actually compliant (guidance too aggressive)
- False negative — the user's app was rejected for something the skill reviewed but didn't flag
- Wrong citation — a real issue, but attributed to the wrong guideline section or given the wrong risk level
- Outdated — a rule here contradicts Apple's current published guidelines
Usefulness
- Too noisy — a flood of low-value or duplicate findings drowned out the ones that mattered
- Not actionable — a finding lacked the detail, code reference, or concrete fix needed to act on it
- Bad fix — a suggested remediation was wrong, deprecated, didn't work, or would itself be rejected (including Swift vs React Native/Expo specifics)
Coverage
- Missing rule — a review scenario, API, or storefront-specific requirement (EU, Brazil, Korea, US, ...) the skill doesn't cover
- Contradiction — two parts of this skill disagree with each other
Behavior
- Trigger/weight — the skill activated when irrelevant, failed to activate when it should have, or consumed excessive context
- Unclear — the user found guidance confusing, ambiguous, or hard to apply
Softer signals count too: if the user repeatedly dismisses the same kind of finding, overrides the skill's advice and turns out to be right, or visibly works around a checklist item, that is feedback worth offering to file — micro-friction is as valuable as a wrong rule.
Consent rules — all mandatory, no exceptions:
- Ask first. Say something like: "This looks like a gap in the app-store-review skill itself. Want me to draft a GitHub issue so the maintainer can fix it?" If the user declines, drop it for the rest of the session.
- Show the full draft (exact title and body) before anything is sent.
- Never include the user's code, app name, bundle IDs, file paths, credentials, or proprietary details. The report is about this skill's rules, not the user's app. Only include such details if the user explicitly writes them into the draft themselves.
- Send only after the user approves the exact text, using
gh issue create --repo safaiyeh/app-store-review-skill --title "..." --body "...". If gh is unavailable or unauthenticated, give the user this link to file it themselves: https://github.com/safaiyeh/app-store-review-skill/issues/new?template=skill-feedback.yml
- Never send feedback silently, automatically, or as a side effect of another task. A declined permission prompt means no — do not retry or find another route.
Issue content: skill version (from the frontmatter above), the feedback category, the rule section involved (e.g. "3.1.1"), what the skill said or did, what should have happened instead, and today's date. Nothing else unless the user adds it.
References
