App Store Preflight Skills

App Store Preflight Skill

Run pre-submission checks on your iOS/macOS project to catch common App Store rejection patterns.

Prerequisites

• asc CLI — Install via Homebrew: brew install asc (App-Store-Connect-CLI)
• ASC CLI Skills — app-store-connect-cli-skills for asc usage patterns
• jq — Optional, but used by some JSON-inspection examples in the rule docs

Step 1: Identify App Type → Load Checklist

Determine which guidelines apply by loading the relevant checklist from references/guidelines/by-app-type/. Always start with all_apps.md, then add the app-type-specific one:

Full guideline index: references/guidelines/README.md

Step 2: Pull Metadata for Inspection

Pull the latest App Store metadata using the asc CLI:

# Pull canonical metadata JSON for the version you want to review
asc metadata pull --app "<APP_ID>" --version "<VERSION>" --dir ./metadata

asc metadata pull writes app info files to ./metadata/app-info/*.json and version-localization files to ./metadata/version/<VERSION>/*.json.

Most rule examples below assume the canonical JSON layout written by asc metadata pull.

If you already have metadata in another layout (for example fastlane metadata/), either adapt the file-path examples to that structure or pull the canonical asc layout first.

Step 3: Run Rejection Rule Checks

For each category, load the relevant rule files from references/rules/ and inspect. Each rule contains: What to Check, How to Detect, Resolution, and Example Rejection.

Step 4: Report Findings

Produce a summary report using this template:

## Preflight Report

### ❌ Rejections Found (N)
- [GUIDELINE X.X.X] Description of issue
  - File: path/to/offending/file
  - Fix: What to do

### ⚠️ Warnings (N)
- [GUIDELINE X.X.X] Potential issue

### ✅ Passed (N)
- [Category] All checks passed

Order by severity: rejections first, then warnings, then passed.

Step 5: Autofix + Validate

Some issues can be auto-fixed:

• Competitor terms → Suggest replacement text with competitor names removed
• Metadata character limits → Show current vs. max length
• Missing links → Generate template ToS/PP URLs

After applying any auto-fix, re-run the affected checks to confirm the fix resolved the violation. Only mark as resolved once the re-scan passes.

For issues requiring manual intervention (screenshots, UI redesign), provide clear instructions but do not auto-fix.

Gotchas

• China storefront — Banned AI terms (ChatGPT, Gemini, etc.) are checked across ALL locales, not just zh-Hans. Apple checks every locale visible in the China storefront.
• Privacy manifests — PrivacyInfo.xcprivacy is required even if your app doesn't call Required Reason APIs directly. Third-party SDKs (Firebase, Amplitude, etc.) that use UserDefaults or NSFileManager trigger this requirement transitively.
• asc auth — asc metadata pull requires App Store Connect authentication. Run asc auth login first, or set ASC_KEY_ID, ASC_ISSUER_ID, and one of ASC_PRIVATE_KEY_PATH / ASC_PRIVATE_KEY / ASC_PRIVATE_KEY_B64. If you're unsure what asc is picking up, run asc auth doctor.
• Subscription metadata — Apple requires ToS/PP links in BOTH the App Store description AND the in-app subscription purchase screen. Missing either one is a separate rejection.
• macOS entitlements — Apple will ask you to justify every temporary exception entitlement (com.apple.security.temporary-exception.*). Remove entitlements you don't actively use.

Adding New Rules

Create a .md file in the appropriate references/rules/ subdirectory:

# Rule: [Short Title]
- **Guideline**: [Apple Guideline Number]
- **Severity**: REJECTION | WARNING
- **Category**: metadata | subscription | privacy | design | entitlements

## What to Check
## How to Detect
## Resolution
## Example Rejection

✈️ App Store Preflight

An AI agent skill that runs pre-submission checks on your iOS/macOS project to catch common mistakes that lead to App Store rejection.

Overview

Preflight helps developers catch potential App Store Review guideline violations before submitting their app. It scans your Xcode project, source code, metadata, and configuration files to flag issues that commonly result in rejections from Apple.

This skill integrates with the `asc` CLI (brew install asc) and the ASC CLI Skills to pull and inspect App Store metadata.

Most metadata examples assume the canonical JSON layout written by asc metadata pull. If you are starting from fastlane metadata, adapt the path examples or pull the canonical asc layout first.

Install

npx skills add truongduy2611/app-store-preflight-skills

Guideline Index (by App Type)

The references/guidelines/ directory contains a complete index of all 100+ Apple Review Guidelines and 10 app-type specific checklists:

📖 Full guideline reference: references/guidelines/README.md

How It Works

1. Identify app type → load the matching checklist from references/guidelines/by-app-type/ 2. Pull metadata using asc metadata pull --app "<APP_ID>" --version "<VERSION>" --dir ./metadata (or the asc-metadata-sync skill) 3. Scan against rejection rules in references/rules/ 4. Report findings with severity, affected files, and resolution steps 5. Autofix + Validate — apply fixes, re-run affected checks

See `SKILL.md` for the full AI agent instructions.

Rejection Rules

All rules live in references/rules/, organized by category:

Metadata (references/rules/metadata/)

Subscriptions (references/rules/subscription/)

Privacy (references/rules/privacy/)

Design (references/rules/design/)

Entitlements (references/rules/entitlements/)

Adding New Rules

Create a .md file in the appropriate references/rules/ subdirectory:

# Rule: [Short Title]
- **Guideline**: [Apple Guideline Number]
- **Severity**: REJECTION | WARNING
- **Category**: metadata | subscription | privacy | design | entitlements

## What to Check
## How to Detect
## Resolution
## Example Rejection

Related Skills

• app-store-connect-cli-skills — ASC CLI skills for metadata sync, ASO audit, release flow

License

MIT

Checklist: AI-Powered / Generative AI Apps

Guidelines specifically applying to apps that use AI services (ChatGPT, Gemini, Claude, etc.), generative AI, or deep synthesis technology.

Critical (Will Reject)

• [ ] 5 (China DST) — If distributing in China: remove all references to OpenAI, ChatGPT, GPT, Gemini, Claude, Anthropic, Midjourney, DALL-E from metadata
• [ ] 5 (China DST) — If distributing in China: suppress AI functionality or obtain MIIT license
• [ ] 1.1.6 — No false information or misleading AI capabilities (e.g., "AI doctor")
• [ ] 1.4.1 — AI health advice: must include medical disclaimers; can't substitute for professional diagnosis
• [ ] 2.3.1 — All AI features documented in review notes; no hidden AI capabilities

Important (Common Rejections)

• [ ] 5.2.5 — Don't use "GPT", "ChatGPT", "OpenAI", "Gemini" as part of app name unless you are the brand owner
• [ ] 2.3.7 — Don't keyword-stuff with AI brand names (ChatGPT, GPT-4, Gemini, etc.)
• [ ] 1.2 — If AI generates user-facing content: implement content moderation/filtering
• [ ] 5.1.1 — Disclose AI data processing in privacy policy
• [ ] 2.5.14 — Explicit consent required for AI processing of user recordings/inputs
• [ ] 5.1.1(iii) — Data minimization: don't send more data to AI than necessary
• [ ] 3.1.1 — AI features/credits unlocked via IAP (not external payment for digital content)

China Storefront Specific

Banned AI terms in metadata for China (all locales, not just zh-Hans):

• ChatGPT, GPT-4, GPT-4o, GPT
• OpenAI
• Gemini, Bard (Google)
• Claude, Anthropic
• Midjourney, DALL-E, DALL·E
• Copilot (in AI context)
• Stable Diffusion (cloud API context)

Options

1. Remove references → Use "AI-powered" / "smart assistant" generically 2. Exclude China → Deselect China mainland in App Store Connect 3. Obtain compliance → Get MIIT license for DST services

Checklist: All Apps (Universal Guidelines)

Guidelines that apply to every app regardless of category. Check these before every submission.

Pre-Submission Essentials

• [ ] 2.1 — App is final, complete, tested for crashes and bugs
• [ ] 2.1 — All metadata is complete and accurate (no placeholder text, empty URLs)
• [ ] 2.1 — Demo account provided (or demo mode with prior Apple approval)
• [ ] 2.1 — Backend services are live and accessible during review
• [ ] 2.1(b) — All configured IAP items are findable and functional (or explained in review notes)
• [ ] 2.1 — Review notes include all 6 required new-submission sections (see references/rules/metadata/review_notes_new_submission.md)
• [ ] 2.3 — Review notes describe all non-obvious features

Metadata

• [ ] 2.3.7 — App name ≤ 30 characters; unique; no trademark stuffing
• [ ] 2.3.7 — No pricing info, other app names, or irrelevant phrases in metadata
• [ ] 2.3.10 — No competitor platform names/icons (Android, Google Play, etc.)
• [ ] 2.3.3 — Screenshots show app in use (not just title art, login, or splash)
• [ ] 2.3.4 — App preview videos: screen captures only (no device frames)
• [ ] 2.3.8 — Metadata adheres to 4+ age rating (icons, screenshots, previews)
• [ ] 2.3.9 — Rights secured for all materials; fictional account data in screenshots
• [ ] 2.3.12 — What's New text describes significant changes
• [ ] 5.2.5 — No Apple product images in app icon; no confusing Apple trademarks

Privacy & Data

• [ ] 5.1.1(i) — Privacy policy linked in App Store Connect AND accessible in-app
• [ ] 5.1.1(ii) — User consent secured for all data collection
• [ ] 5.1.1(iii) — Only request data relevant to core functionality
• [ ] 5.1.1(v) — If account creation exists, account deletion must be offered
• [ ] 5.1.2 — ATT framework required for cross-app tracking
• [ ] Privacy Manifest — PrivacyInfo.xcprivacy includes all Required Reason APIs

Design & UX

• [ ] 4.1 — Not a copycat of another app
• [ ] 4.2 — Meaningful functionality beyond a repackaged website
• [ ] 4.8 — If social logins offered, must also offer Sign in with Apple (or equivalent)
• [ ] 4.0 — Sign in with Apple: don't re-ask name/email already provided by SIWA
• [ ] 2.5.1 — Only public APIs; current OS; frameworks for intended purposes
• [ ] 2.5.5 — Fully functional on IPv6-only networks
• [ ] 2.5.14 — Explicit consent for recording user activity

Business

• [ ] 3.1.1 — Digital content unlocks use IAP
• [ ] 3.2.1(x) — Not forcing users to rate/review to access features
• [ ] 1.5 — Support URL with easy contact method
• [ ] 5.6.2 — Developer identity information is accurate and verifiable

Checklist: Crypto, Finance & Trading Apps

Guidelines specifically applying to cryptocurrency wallets, exchanges, trading platforms, banking, and financial service apps.

Critical (Will Reject)

• [ ] 3.1.5(i) — Crypto wallets: developer must be enrolled as an organization (not individual)
• [ ] 3.1.5(ii) — No on-device cryptocurrency mining (cloud-based mining OK)
• [ ] 3.1.5(iii) — Crypto exchanges: only in jurisdictions with appropriate licensing
• [ ] 3.1.5(iv) — ICOs, futures, crypto-securities trading: from established banks/financial institutions only
• [ ] 3.1.5(v) — No offering crypto for completing tasks (downloading apps, social posting, etc.)
• [ ] 3.2.2(viii) — No binary options trading apps
• [ ] 3.2.2(viii) — CFD/FOREX apps: properly licensed in all service jurisdictions
• [ ] 3.2.2(ix) — Loan apps: APR ≤ 36%; repayment > 60 days; clearly disclose all terms
• [ ] 5.1.1(ix) — Banking, financial services, crypto exchanges: submit as legal entity, not individual

Important (Common Rejections)

• [ ] 5.1.1(i) — Privacy policy clearly describes financial data collection and handling
• [ ] 3.1.1 — Digital content within app must use IAP; crypto can't be used to unlock features
• [ ] 3.1.1 — NFT ownership must not unlock features or functionality
• [ ] 1.1.6 — No false financial information or misleading investment claims
• [ ] 2.3.1 — All financial functionality documented in review notes
• [ ] 5.1.1(v) — Account deletion must be offered if account creation exists
• [ ] 1.6 — Appropriate security measures for financial data

NFT-Specific

• [ ] 3.1.1 — NFTs sold/minted via IAP
• [ ] 3.1.1 — NFT ownership cannot unlock app features or functionality
• [ ] 3.1.1 — Browsing others' NFTs: no external purchase links (except US storefront)

Checklist: Games

Guidelines specifically applying to games, including casual, hardcore, streaming, and gambling apps.

Critical (Will Reject)

• [ ] 3.1.1 — All in-game currency, levels, and premium content purchased via IAP
• [ ] 3.1.1 — Loot boxes / gacha mechanics: odds must be disclosed before purchase
• [ ] 3.1.1 — In-game currencies purchased via IAP do not expire
• [ ] 3.1.1 — Restore Purchases mechanism for restorable items
• [ ] 1.1.2 — Game enemies cannot solely target a specific race, culture, real government, or real corporation
• [ ] 5.3 — Gambling/betting: licensed in the jurisdictions where offered
• [ ] 5.3 — Lottery apps: only from lottery entities or their authorized partners

Important (Common Rejections)

• [ ] 2.3.6 — Age rating honestly answers all content questions (violence, mature themes, etc.)
• [ ] 2.3.8 — Metadata icons/screenshots adhere to 4+ age rating even if game is rated higher
• [ ] 2.4.3 — Apple TV: must work with Siri remote; explain if game controller required
• [ ] 4.2.1 — ARKit games: provide rich AR experience, not just dropping a model
• [ ] 3.1.2(a) — Streaming game subscriptions: download from App Store; avoid duplicate payment
• [ ] 2.4.2 — No crypto mining (even background); no excessive battery drain
• [ ] 1.4.5 — No encouraging dangerous real-world bets or challenges
• [ ] 3.1.2(a) — If switching to subscription model, don't remove content already paid for ("full game unlock")

Game-Specific Design

• [ ] 4.2 — Must provide lasting entertainment value
• [ ] 4.3 — No submitting duplicate/near-identical game variants to spam the store
• [ ] 2.3.3 — Screenshots show the actual game in play, not just title art
• [ ] 5.5.5 — Game Center: don't reverse-lookup Player IDs or exploit player data

Checklist: Health, Fitness & Medical Apps

Guidelines specifically applying to health tracking, fitness, medical, and HealthKit-integrated apps.

Critical (Will Reject)

• [ ] 1.4.1 — Medical apps: clearly disclose data and methodology for accuracy claims
• [ ] 1.4.1 — Cannot claim sensor-only diagnostics (x-rays, blood pressure, blood glucose, SpO2)
• [ ] 1.4.1 — Must remind users to check with a doctor before making medical decisions
• [ ] 1.4.2 — Drug dosage calculators: must come from approved medical entities (manufacturer, hospital, university, FDA-approved)
• [ ] 5.1.3(i) — HealthKit data: NO use for advertising, marketing, or data mining
• [ ] 5.1.3(ii) — Must not write false or inaccurate data into HealthKit
• [ ] 5.1.3(ii) — Must not store personal health data in iCloud
• [ ] 5.1.3(iii) — Health research: informed consent required (nature, purpose, duration, risks, confidentiality, withdrawal)
• [ ] 5.1.3(iv) — Health research: independent ethics review board approval required

Important (Common Rejections)

• [ ] 5.1.1 — Privacy policy clearly describes health data collection and use
• [ ] 2.5.1 — HealthKit used for health/fitness purposes and integrates with Health app
• [ ] 5.1.1(iii) — Data minimization: only collect health data relevant to core functionality
• [ ] 1.4.1 — If regulatory clearance received (FDA, etc.), submit link with app
• [ ] 5.1.1(ix) — Healthcare apps: submit as legal entity, not individual developer
• [ ] 2.5.18 — No targeted ads based on health/medical data (HealthKit APIs)

HealthKit Specific

• [ ] HealthKit framework used only for health and fitness purposes
• [ ] Data not shared with third parties for advertising/marketing
• [ ] User consent obtained for all data access
• [ ] No false data written to Health app

Checklist: Kids Category Apps

Guidelines specifically applying to apps in the Kids Category or apps targeting children.

Critical (Will Reject)

• [ ] 1.3 — No external links (unless behind parental gate)
• [ ] 1.3 — No purchasing opportunities (unless behind parental gate)
• [ ] 1.3 — No third-party advertising
• [ ] 1.3 — No third-party analytics (limited exceptions: no IDFA, no PII, no location)
• [ ] 5.1.4(a) — COPPA / GDPR compliance for children's data
• [ ] 5.1.4 — No sending PII or device info to third parties
• [ ] 5.1.4 — Privacy policy required and must comply with children's privacy statutes
• [ ] 5.1.1(i) — Privacy policy linked in App Store Connect AND accessible in-app

Important (Common Rejections)

• [ ] 2.3.8 — "For Kids" / "For Children" in metadata is reserved for Kids Category
• [ ] 1.3 — Once in Kids Category, must continue meeting guidelines in all subsequent updates
• [ ] 5.1.4(b) — Third-party contextual ads only if service has documented Kids-specific policies with human review
• [ ] 2.3.6 — Age rating accurately reflects content
• [ ] 2.5.18 — No ads in extensions, widgets, App Clips, keyboards, or watchOS

Parental Gate Requirements

• [ ] Areas with external links, purchases, or distractions must be behind a parental gate
• [ ] Parental gate guidance followed

Checklist: macOS / Mac App Store Apps

Guidelines specifically applying to apps distributed via the Mac App Store, including sandboxing, entitlements, and macOS-specific requirements.

Critical (Will Reject)

• [ ] 2.4.5(i) — App must be appropriately sandboxed
• [ ] 2.4.5(i) — Only use appropriate macOS APIs for modifying data from other apps
• [ ] 2.4.5(i) — Entitlements must match actual app functionality (Apple will ask for justification)
• [ ] 2.4.5(ii) — Packaged and submitted using Xcode; no third-party installers
• [ ] 2.4.5(ii) — Self-contained, single app installation bundle
• [ ] 2.4.5(iii) — No auto-launch at startup/login without consent
• [ ] 2.4.5(iii) — No spawning background processes after user quits
• [ ] 2.4.5(iii) — No auto-adding icons to Dock or desktop shortcuts
• [ ] 2.4.5(iv) — No downloading standalone apps, kexts, or additional code
• [ ] 2.4.5(v) — No requesting root privileges or setuid attributes
• [ ] 2.4.5(vi) — No license screens at launch; no license keys; no custom copy protection
• [ ] 2.4.5(vii) — Updates distributed via Mac App Store only
• [ ] 2.4.5(viii) — Must run on currently shipping OS; no deprecated technologies (Java)
• [ ] 2.4.5(ix) — All localizations in a single app bundle

Important (Common Rejections)

• [ ] 2.5.1 — Only public APIs; frameworks used for intended purposes
• [ ] 2.5.2 — Self-contained in bundle; no reading/writing outside designated container
• [ ] 2.3.10 — Metadata focused on macOS experience; no iOS-only language in description
• [ ] 5.2.5 — No Apple device images in app icon
• [ ] 5.1.1(i) — Privacy policy required
• [ ] 2.5.5 — Fully functional on IPv6-only networks

Entitlements Audit

Common entitlements that trigger Apple review questions:

• [ ] com.apple.security.network.server — Justify if app acts as a local server
• [ ] com.apple.security.network.client — Standard for network requests
• [ ] com.apple.security.files.downloads.read-only — Justify Downloads folder access
• [ ] com.apple.security.files.user-selected.read-write — Standard for file picker
• [ ] com.apple.security.temporary-exception.* — Will draw extra scrutiny

Checklist: Social / User-Generated Content Apps

Guidelines specifically applying to social networking, messaging, community, and UGC platform apps.

Critical (Will Reject)

• [ ] 1.2 — Content moderation: filter for objectionable material
• [ ] 1.2 — Report mechanism for offensive content with timely responses
• [ ] 1.2 — Ability to block abusive users
• [ ] 1.2 — Published contact information for user support
• [ ] 4.8 — If offering third-party login (Facebook, Google, etc.), must also offer Sign in with Apple or equivalent
• [ ] 4.0 — Sign in with Apple: don't re-ask name/email after SIWA auth
• [ ] 5.1.1(v) — If account creation exists, must also offer account deletion
• [ ] 5.1.1(v) — Must provide access without social login if core functionality isn't social-network-specific
• [ ] 5.1.1(i) — Privacy policy required (in-app + App Store Connect)

Important (Common Rejections)

• [ ] 1.2.1 — Creator content apps: age-restriction mechanism for content exceeding app rating
• [ ] 1.1.1 — No defamatory, discriminatory, or mean-spirited content
• [ ] 2.5.14 — Explicit consent for recording user activity (camera, microphone, screen)
• [ ] 5.1.1(ii) — User consent for data collection; clear purpose strings
• [ ] 5.1.2 — ATT framework required for cross-app tracking
• [ ] 5.1.1(viii) — No compiling personal info from non-user sources (public databases)
• [ ] 4.5.4 — Push notifications: not required to function; opt-in for marketing
• [ ] 5.1.1(iii) — Data minimization: only request data relevant to core functionality

UGC-Specific Rules

• [ ] NSFW content from web services: hidden by default, opt-in via website only
• [ ] No Chatroulette-style random chat, anonymous bullying, or "hot-or-not" voting
• [ ] No apps primarily used for pornographic content

Checklist: Apps with Subscriptions / In-App Purchases

Guidelines that specifically apply to apps offering auto-renewable subscriptions, consumable/non-consumable IAP, or freemium models.

Critical (Will Reject)

• [ ] 3.1.1 — All digital content unlocks use Apple's In-App Purchase (no license keys, QR codes, crypto)
• [ ] 3.1.2(a) — Subscription provides ongoing value; minimum 7-day period; works on all user devices
• [ ] 3.1.2(c) — Subscription purchase screen clearly describes what user gets for the price
• [ ] 3.1.2 — Billed amount is the most prominent pricing element (not calculated monthly price)
• [ ] 3.1.2 — App description includes functional Terms of Use (EULA) link
• [ ] 3.1.2 — App description includes functional Privacy Policy link
• [ ] 5.1.1(i) — Privacy Policy URL set in App Store Connect metadata
• [ ] 3.1.1 — Loot boxes / randomized items disclose odds before purchase
• [ ] 3.1.1 — In-game currencies purchased via IAP do not expire
• [ ] 3.1.1 — Restore Purchases mechanism exists for restorable IAP
• [ ] 2.1(b) — All IAP items are complete, visible to reviewer, and functional

Important (Common Rejections)

• [ ] 3.1.2(b) — Seamless upgrade/downgrade; no accidental duplicate subscriptions
• [ ] 2.3.2 — Description/screenshots clearly indicate which features require additional purchase
• [ ] 3.1.2(a) — Not taking away functionality previously paid for when switching to subscription model
• [ ] 3.1.2(a) — Free trial clearly identifies duration, what ends, and post-trial charges
• [ ] 4.10 — Not charging for built-in OS capabilities (Push, camera, iCloud)
• [ ] 3.2.1(x) — Not forcing users to rate/review app to access features

In-App Subscription Screen Must Include

• [ ] Title of subscription
• [ ] Length of subscription period
• [ ] Price (and price per unit if appropriate)
• [ ] Functional tappable Privacy Policy link
• [ ] Functional tappable Terms of Use / EULA link

Checklist: VPN & Networking Apps

Guidelines specifically applying to VPN, proxy, and network management apps.

Critical (Will Reject)

• [ ] 5.4 — Must use the NEVPNManager API
• [ ] 5.4 — Must be from developers enrolled as an organization
• [ ] 5.4 — Must not collect any user data
• [ ] 5.4 — Must not use VPN profiles to block ads, redirect traffic for monetization, or collect/sell data
• [ ] 5.4 — Must clearly state what data is collected and how it is used on-screen before any data access

Important

• [ ] 5.1.1 — Privacy policy required
• [ ] 2.5.5 — Fully functional on IPv6-only networks
• [ ] 2.3.1 — All app functionality documented in review notes
• [ ] 3.1.1 — Premium VPN features must use IAP (not external payment for digital service)

Apple App Store Review Guidelines — Complete Reference

Source: App Store Review Guidelines

This is a structured index of every guideline section, organized for quick lookup. Use the app-type checklists to find which guidelines apply to your specific type of app.

---

Section 1: Safety

---

Section 2: Performance

---

Section 3: Business

---

Section 4: Design

---

Section 5: Legal

Rule: Minimum Functionality

• Guideline: 4.2
• Severity: REJECTION
• Category: design

What to Check

Apple requires apps to provide "valuable utility or entertainment" and be more than a repackaged website, simple wrapper, or thin shell. Apps rejected under 4.2 typically:

• Have only 1-2 screens with minimal interactivity
• Are essentially a WebView wrapping a website
• Provide no functionality beyond what Safari offers
• Are a simple collection of links or RSS feed
• Consist primarily of marketing material or a product catalog
• Are a book or game guide that should be on Apple Books instead
• Are template-generated apps with no unique content

Related Sub-Guidelines

How to Detect

Code-Level Signals

# Check if app is primarily a WebView wrapper
grep -rn "WKWebView\|UIWebView\|WebView\|SFSafariViewController" --include="*.swift" --include="*.m" .

# Count total view controllers / screens
grep -rn "class.*:.*UIViewController\|class.*:.*View {" --include="*.swift" . | wc -l

# Check for meaningful model/data layer
find . -name "*.swift" -path "*/Model*" -o -name "*.swift" -path "*/Models*" | wc -l

# Check if app has any local data persistence
grep -rn "CoreData\|SwiftData\|UserDefaults\|Realm\|SQLite\|KeychainSwift" --include="*.swift" .

Red Flags

• < 3 unique screens → Very likely to trigger 4.2
• Single WebView loading an external URL as the primary experience
• No model layer — no local data structures beyond what the web provides
• No offline functionality — completely dependent on network
• Only static content — no user interaction beyond scrolling

App Store Connect Metadata

# Pull and check description — if it's hard to describe what the app DOES, it may lack functionality
asc metadata pull --app "<APP_ID>" --version "<VERSION>" --dir ./metadata
jq -r '.description // empty' ./metadata/version/<VERSION>/<LOCALE>.json | wc -w
# Very short descriptions (< 50 words) can indicate minimal functionality

Resolution

1. Add unique features that go beyond what a website offers:

• Offline mode / local data caching
• Push notifications for relevant events
• Device-specific integrations (camera, location, HealthKit, etc.)
• User-generated content or personalization
• Native UI patterns (swipe actions, drag & drop, widgets)

2. If your app is a web wrapper, consider:

• Adding native authentication (Sign in with Apple, biometrics)
• Implementing native navigation instead of web-based nav
• Adding local storage so the app works offline
• Integrating Apple frameworks (Share Sheet, Spotlight, Shortcuts)

3. In your review notes, clearly explain:

• What the app does that a website can't
• The target audience and use case
• Any features that might not be immediately obvious to the reviewer

Example Rejection

Guideline 4.2 - Design - Minimum Functionality

The usefulness of the app is limited by the minimal functionality it currently
provides.

Specifically, the app does not provide sufficient content and features to be
useful, unique, and "app-like."

Apps should provide valuable utility or entertainment, draw people in by
offering compelling capabilities or content, or enable people to do something
they couldn't do before or in a way they couldn't do it before.

Next Steps

We encourage you to review your app concept and incorporate different content
and features that are in compliance with the App Review Guidelines.

Rule: Sign in with Apple UX Violations

• Guideline: 4.0 – Design
• Severity: REJECTION
• Category: design

What to Check

If the app offers Sign in with Apple (SIWA), the implementation must follow Apple's design and UX requirements. The most common violations:

Common Violations

1. Asking for name/email after SIWA — The Authentication Services framework already provides name and email (if the user chooses to share). Do not prompt for this information again. 2. Non-standard button styling — The SIWA button must use Apple's provided ASAuthorizationAppleIDButton or equivalent, not a custom-designed button. 3. Hidden or de-emphasized SIWA — If other social logins are shown (Google, Facebook, etc.), SIWA must be equally prominent. 4. Not handling the "Hide My Email" relay — The app must work with Apple's relay email addresses (*@privaterelay.appleid.com).

How to Detect

Check for post-SIWA data requests

# Find SIWA implementation
grep -rn "ASAuthorizationAppleIDProvider\|SignInWithApple\|appleIDCredential\|apple.*sign.*in" --include="*.swift" --include="*.dart" .

# Check if name/email is requested AFTER sign-in
grep -rn "askForName\|askForEmail\|nameTextField\|emailTextField\|profileSetup\|completeProfile" --include="*.swift" --include="*.dart" .

Check for relay email handling

# Ensure the app doesn't reject relay emails
grep -rn "privaterelay.appleid.com\|@privaterelay\|email.*validation\|isValid.*email" --include="*.swift" --include="*.dart" .

Visual Inspection

1. Sign in with Apple using the "Hide My Email" option 2. After authenticating, check if the app:

• Shows a form asking for your name (❌ violation)
• Shows a form asking for your email (❌ violation)
• Immediately proceeds to the main app (✅ correct)

Resolution

1. Use the data from SIWA credentials: ASAuthorizationAppleIDCredential provides fullName and email — cache these on first use 2. Don't re-ask for provided data: If the user shared their name/email via SIWA, use it directly 3. Handle missing data gracefully: If the user chose to hide email, use the relay address; if they hid their name, use a default 4. Use standard SIWA button: Use ASAuthorizationAppleIDButton (Swift) or sign_in_with_apple package (Flutter)

Example Rejection

Guideline 4.0 - Design

>

Your app offers Sign in with Apple as a login option but does not follow the design and user experience requirements for Sign in with Apple. Specifically:

>

- Your app requires users to provide their name and/or email address after using Sign in with Apple. This information is already provided by the Authentication Services framework.

>

Next Steps

>

Please revise the Sign in with Apple experience in your app to address the issues we identified above.

Rule: Unused or Unnecessary Entitlements

• Guideline: 2.4.5(i) – Performance
• Severity: REJECTION (info request, blocks review)
• Category: entitlements

What to Check

Apps should only declare entitlements that are actively used by the app. Apple will request justification for any entitlement that doesn't have matching functionality in the app. If you can't justify an entitlement, it must be removed.

Commonly Flagged Entitlements (macOS)

• com.apple.security.network.server — App acts as a network server
• com.apple.security.network.client — App makes outbound network requests
• com.apple.security.files.downloads.read-only — App reads the Downloads folder
• com.apple.security.files.downloads.read-write — App writes to Downloads
• com.apple.security.files.user-selected.read-only — App reads user-selected files
• com.apple.security.files.user-selected.read-write — App writes to user-selected files
• com.apple.security.files.bookmarks.app-scope — App uses security-scoped bookmarks
• com.apple.security.temporary-exception.* — Temporary exceptions (will draw scrutiny)

iOS Capabilities That Add Entitlements

• Push Notifications → aps-environment
• HealthKit → com.apple.developer.healthkit
• Sign in with Apple → com.apple.developer.applesignin
• iCloud → com.apple.developer.icloud-*

How to Detect

Find entitlements files

# Find all entitlements files
find . -name "*.entitlements" -not -path "./.build/*"

Parse entitlements

# List all declared entitlements
plutil -p *.entitlements
# or
cat *.entitlements

Cross-reference with code usage

For each entitlement, verify the app actually uses the capability:

# Network server — is the app running a local server?
grep -rn "NWListener\|GCDWebServer\|Swifter\|Vapor\|HttpServer\|startServer" --include="*.swift" .

# Downloads folder access — does the app read/write Downloads?
grep -rn "Downloads\|downloadsDirectory\|FileManager.*downloads" --include="*.swift" .

# HealthKit — is HealthKit actually used?
grep -rn "HKHealthStore\|HealthKit\|health_kit" --include="*.swift" --include="*.dart" .

Automated audit

# List entitlements from the built app
codesign -d --entitlements :- /path/to/YourApp.app

Resolution

1. Remove unused entitlements: Open the .entitlements file in Xcode and remove keys for capabilities you don't use 2. Remove unused capabilities: In Xcode → Target → Signing & Capabilities, remove capabilities you don't need 3. If the entitlement IS needed: Reply to Apple in App Store Connect explaining how and where the app uses each flagged entitlement 4. Rebuild and resubmit: After removing entitlements, Developer Reject the current submission, rebuild, and upload a new binary

Example Rejection

Guideline 2.4.5(i) - Performance

>

Issue Description

>

In order to continue reviewing the app, we require additional information.

>

The app uses one or more entitlements which do not appear to have matching functionality within the app. Please reply to this message in App Store Connect and describe how and where the app uses the following entitlements.

>

---

• com.apple.security.network.server

• com.apple.security.files.downloads.read-only

---

>

Resources

>

Learn more about Mac App Store requirements in guideline 2.4.5.

Rule: App Preview Contains Device Frames

• Guideline: 2.3.4 – Performance – Accurate Metadata
• Severity: REJECTION
• Category: metadata

What to Check

App preview videos must only contain capture footage of the app running. They must not include:

• Device images or device frames (e.g., an iPhone bezel around the screen)
• Framing around the video screen capture
• Non-app content that obscures the app experience

Note: This applies to app preview videos, not static screenshots. Static screenshots _may_ use device frames.

How to Detect

Manual Inspection

1. Open App Store Connect → your app version → Previews and Screenshots 2. Play each app preview video in full screen 3. Check for:

• Device bezels or phone outlines visible in the video
• Borders, frames, or decorative elements around the screen capture
• Non-app scenes (e.g., lifestyle shots with a person holding a phone)

Using asc CLI

# List current preview video assets for a specific version localization
asc video-previews list --version-localization "<VERSION_LOCALIZATION_ID>"

# Download previews locally for frame-by-frame inspection
asc video-previews download --version-localization "<VERSION_LOCALIZATION_ID>" --output-dir ./previews

Automated Check (ffmpeg frame analysis)

# Extract first frame of each preview for visual inspection
find ./previews -type f \( -name "*.mov" -o -name "*.mp4" \) -print0 | \
  while IFS= read -r -d '' preview; do
    ffmpeg -i "$preview" -vframes 1 -q:v 2 "${preview%.*}_frame.jpg"
  done

Then visually inspect extracted frames for device imagery.

Resolution

1. Re-record app previews using only screen capture (e.g., Xcode Simulator recording, QuickTime screen recording) 2. Remove any device frame overlays from the video 3. Narration and text overlays are allowed for clarity 4. Upload via App Store Connect → "View All Sizes in Media Manager"

Example Rejection

Guideline 2.3.4 - Performance - Accurate Metadata

>

The app preview includes content that does not sufficiently show the app in use. Specifically, the app preview:

>

- Includes framing around the video screen capture.

- Includes device images and/or device frames.

>

App previews should allow users to see what the app does and how it will appear on their device when the preview is played in full screen.

>

Next Steps

>

To resolve this issue, revise the app preview to only use video screen captures of the app that may include narration and video or textual overlays for added clarity.

Rule: Apple Trademark Violations

• Guideline: 5.2.5 – Legal – Intellectual Property
• Severity: REJECTION
• Category: metadata

What to Check

App metadata, icons, and screenshots must not include content confusingly similar to Apple products, services, or trademarks.

Flagged Patterns

App Icon:

• Apple device silhouettes or imagery (iPhone, iPad, Mac, Apple Watch)
• Apple logo or any variation of it
• Icons confusingly similar to Apple's own app icons

App Name / Subtitle:

• Using Apple product names as part of your app name (e.g., "iPhone Cleaner", "iPad Manager")
• Using Apple service names (e.g., "My iCloud Backup", "Siri Helper")

Metadata Text:

• Apple product names used as feature descriptors unnecessarily
• Phrases like "best app in the App Store" (using "App Store" generically)
• Terms like "iPhone app", "iPad edition" in subtitle or description

Screenshots / Marketing:

• Unauthorized 3D renders or simulations of Apple products
• Illustrations of Apple devices (unless for instructional use showing your app running)
• Apple device images placed alongside competitor product images
• Obscuring or exploiting the Apple logo on device images
• Die-cut promotions in the shape of an Apple product
• Using icons, logos, or images sourced directly from apple.com

Commonly Flagged Terms

• iPhone, iPad, Mac, MacBook, Apple Watch, Apple TV, Vision Pro
• iMessage, FaceTime, Siri, AirDrop, iCloud
• App Store (when used generically)
• Apple (when implying endorsement or association)

How to Detect

App Icon

• Visually inspect the app icon asset (AppIcon.appiconset/) for device silhouettes or Apple product imagery
• Check Assets.xcassets/AppIcon.appiconset/Contents.json for references

App Name

# Check app name for Apple product terms
grep -i "iphone\|ipad\|macbook\|apple watch\|apple tv\|imessage\|facetime\|siri\|icloud\|vision pro" \
  ./metadata/app-info/*.json

Metadata Text

# Search all pulled metadata for Apple product terms
grep -ri "iphone\|ipad\|macbook\|apple watch\|apple tv\|imessage\|facetime\|siri\|airdrop\|vision pro" \
  ./metadata/app-info/ ./metadata/version/<VERSION>/

Screenshots

• Visually inspect all screenshot assets for:
• Unauthorized Apple device renders (3D models, illustrations, die-cuts)
• Apple logo exploitation (centering on or enhancing the Apple logo)
• Apple devices shown next to competitor devices (Samsung, Google, etc.)
• Allowed: Showing your app running on a real Apple device in screenshots, as long as the device illustrates natural use and is not the focal point

Resolution

1. App Icon: Remove any Apple device imagery; use abstract or product-specific design instead 2. App Name: Remove Apple product names from app name/subtitle:

• "iPhone Cleaner Pro" → "Phone Cleaner Pro"
• "My iPad Manager" → "My Tablet Manager"

3. Metadata: Remove or rephrase Apple product references:

• "Works with iPhone" → "Works with your phone" (if it's a universal claim)
• "Download on App Store" → remove (users are already on the App Store)
• "Best Siri alternative" → "Best voice assistant"

4. Screenshots: Replace unauthorized renders with real device screenshots or remove device frames entirely 5. Apple device photos: If showing an Apple device, ensure it shows your app in natural use; don't place alongside competitor products

Example Rejection

Guideline 5.2.5 - Legal - Intellectual Property

>

Issue Description

>

The app's metadata includes content that is similar to designs or terms used for Apple products and services and may cause confusion for users. Specifically, your metadata includes:

>

- iPhone device found in the application icon

>

Next Steps

>

To resolve this issue, remove images and terms that are confusingly similar to an Apple product or service from the app's metadata.

>

Resources

>

- Learn more about appropriate and inappropriate use of Apple trademarks in the Guidelines for Using Apple's Trademarks and Copyrights.

Rule: AI Service References for China Storefront

• Guideline: 5 – Legal (Chinese DST Regulations)
• Severity: REJECTION
• Category: metadata

What to Check

Apps distributed on the China mainland storefront must not reference AI services that lack the required Chinese government permits (MIIT license). This applies to both metadata and in-app functionality.

Banned Terms (China Storefront)

• ChatGPT, GPT-4, GPT-4o, GPT
• OpenAI
• Gemini (Google), Bard
• Claude, Anthropic
• Midjourney, DALL-E, DALL·E
• Copilot (in AI context)
• Stable Diffusion (when referencing cloud API)
• Any deep synthesis technology (DST) service without a Chinese MIIT license

Metadata Fields to Check

• App name
• Subtitle
• Promotional text
• App description
• Keywords
• Screenshots (text overlays)
• What's New

How to Detect

Using asc CLI

# Pull canonical metadata for all locales in the version under review
asc metadata pull --app "<APP_ID>" --version "<VERSION>" --dir ./metadata

# Check Chinese locale specifically
grep -i "chatgpt\|openai\|gpt-4\|gemini\|claude\|anthropic\|midjourney\|dall-e\|copilot\|bard" \
  ./metadata/app-info/zh-Hans.json ./metadata/version/<VERSION>/zh-Hans.json 2>/dev/null

Check all locales (Apple reviews all, not just zh-Hans)

# Apple may flag ANY locale if the app is distributed in China
grep -ri "chatgpt\|openai\|gpt-4\|gemini\|claude\|anthropic\|midjourney\|dall-e" \
  ./metadata/app-info/ ./metadata/version/<VERSION>/

Check storefront availability

Verify whether China mainland is included in the app's availability settings in App Store Connect.

Resolution

Option A: Remove references (keep China distribution)

1. Remove all AI service brand names from metadata across all locales 2. Use generic terms: "AI-powered" or "smart assistant" instead of brand names 3. Suppress AI functionality specifically for the China storefront build 4. Update Review Notes to confirm AI functionality is suppressed in China

Option B: Exclude China storefront

1. In App Store Connect → Pricing and Availability → Deselect "China mainland" 2. Keep AI references in metadata for all other storefronts

Option C: Obtain compliance

Seek professional advice on compliance with the Administrative Provisions on Deep Synthesis of Internet-based Information Services to obtain the required MIIT permits.

Example Rejection

Guideline 5 - Legal

>

Issue Description

>

As you may know, the Chinese government has been tightening regulations associated with deep synthesis technologies (DST) and generative AI services, including ChatGPT. DST must fulfill permitting requirements to operate in China, including securing a license from the Ministry of Industry and Information Technology (MIIT) if the services are provided while connected to the Internet.

>

Based on our review, the app appears to be associated with ChatGPT, which does not have requisite permits to operate in China. Specifically, the app's metadata includes the following references to ChatGPT and/or OpenAI: OpenAI.

>

Accordingly, pursuant to local Chinese law, this functionality must be deactivated in the version of the app that you make available on the China App Store and all references to ChatGPT or OpenAI must be removed from metadata fields such as app name, subtitle, promotional text, app description, and screenshots.

Rule: Competitor Platform Terms in Metadata

• Guideline: 2.3.1 – Performance – Accurate Metadata
• Severity: REJECTION
• Category: metadata

What to Check

App Store metadata (name, subtitle, description, keywords, promotional text, What's New) must not reference competing platforms or brands.

Banned Terms

• Android, Google Play, Google Play Store
• Samsung, Galaxy Store
• Huawei, AppGallery
• Amazon Appstore
• Windows Store, Microsoft Store
• APK, sideload

How to Detect

Using asc CLI (pulled metadata)

# Pull canonical metadata first
asc metadata pull --app "<APP_ID>" --version "<VERSION>" --dir ./metadata

# Search across app-info and version localizations
grep -ri "android\|google play\|samsung\|huawei\|apk\|amazon appstore\|windows store\|microsoft store" \
  ./metadata/app-info/ ./metadata/version/<VERSION>/

Using local fastlane metadata

grep -ri "android\|google play\|samsung\|huawei\|apk\|amazon appstore\|windows store\|microsoft store" ./fastlane/metadata/

In Xcode project (Info.plist)

grep -ri "android\|google play" *.xcodeproj/project.pbxproj

Resolution

1. Remove all references to competing platforms from metadata fields 2. Replace with generic terms:

• "Available on Android" → "Available on multiple platforms"
• "Also on Google Play" → remove entirely
• "Transfer from Android" → "Transfer from your previous device"

3. Re-verify using asc metadata push --app "<APP_ID>" --version "<VERSION>" --dir ./metadata --dry-run before uploading

Example Rejection

Guideline 2.3.1 - Performance - Accurate Metadata

>

We noticed that your app's metadata includes references to other mobile platforms, which is not appropriate for the App Store. Specifically, the following content was found:

- "Android" mentioned in the app description

>

Next Steps: Remove all references to other mobile platforms from the app's metadata.

Rule: Review Notes — New Submission Completeness

• Guideline: 2.1
• Severity: REJECTION
• Category: metadata

What to Check

For every new app submission (first-time apps or major new versions), review notes must include all six of the following sections. Omitting any section commonly triggers a rejection or an Information Needed response from Apple.

1. Screen Recording on a Physical Device

A screen recording captured on a physical device demonstrating the app's functionality. The recording must:

• Begin with launching the app
• Show the typical user flow through core features

If the app includes any of the following, they must appear in the recording:

• Account registration, login, and account deletion flows
• Accessing paid content or features, including any purchase or subscription flows
• User-generated content, including content reporting and blocking mechanisms
• Any prompts requesting access to sensitive data or device capabilities (e.g., location, contacts, camera, microphone)

2. App Purpose Description

A description of the app's purpose, including:

• The problem it solves
• The value it provides to its intended audience

3. Access Instructions and Test Credentials

Instructions for accessing and reviewing the app's main features, including:

• Any required test or login credentials (username/password, demo account)
• Steps to reach non-obvious or gated features

4. External Services List

A list of the external services, tools, or platforms the app uses to deliver its core functionality. Examples:

• Data providers
• Authentication services (Firebase Auth, Auth0, etc.)
• Payment processors (Stripe, RevenueCat, etc.)
• AI services (OpenAI, Google AI, etc.)
• Analytics platforms
• Cloud storage providers

5. Regional Differences

One of the following:

• A description of any regional differences in the app's features or content
• A confirmation that the app functions consistently across all regions

6. Regulated Industry Documentation (if applicable)

If the app operates in a highly regulated industry (healthcare, finance, gambling, insurance, legal, etc.), include:

• Relevant documentation or credentials demonstrating authorization to provide these services
• Applicable licenses, certifications, or regulatory approvals

How to Detect

1. Pull review notes from App Store Connect metadata:

   asc metadata pull --output-dir ./metadata

Or inspect the local metadata/review_information/notes.txt (fastlane convention).

2. Scan the review-notes text for the presence of each section. Look for:

• A link to a screen recording (URL, or mention of "screen recording" / "video" / "demo recording")
• Keywords indicating app purpose ("purpose", "problem", "value", "solves")
• Test credentials or login instructions ("test account", "demo account", "username", "password", "credentials")
• External service mentions (any service names, or a section labeled "external services" / "third-party services")
• Regional info ("region", "all regions", "consistent across", "regional differences")
• Regulated industry docs (only required if app type is in a regulated category)

3. Flag missing sections — any of the 6 sections not found in the review notes should be flagged as a rejection risk.

Resolution

Fill in all missing sections in the review notes. Use the template at `review_notes_template.md` as a starting point.

Key tips:

• Screen recording: Record on a real device (not simulator). Upload to a hosting service and paste the URL in review notes. Keep it under 5 minutes.
• Test credentials: Create a dedicated demo account that won't expire during review (allow at least 2 weeks).
• External services: Be thorough — Apple wants to understand your app's dependencies.
• Regional differences: If your app behaves the same everywhere, a single sentence confirming this is sufficient.

Example Rejection

Guideline 2.1 — Information Needed

>

We need additional information to continue the review of your app.

>

Next Steps: Please provide the following information for us to proceed with your review:

>

- A screen recording, captured on a physical device, that demonstrates the app's functionality. The recording should begin from launching the app and include the typical user flow.

- A description of the app's purpose, including the problem it solves and the value it provides.

- Instructions for accessing the app's main features, including any required test credentials.

- A list of external services used to deliver the app's core functionality.

- Describe any regional differences, or confirm that the app functions consistently across all regions.

Review Notes Template — New App Submission

Copy this template into your App Store Connect review notes (or metadata/review_information/notes.txt for fastlane) and fill in each section before submitting.

---

1. Screen Recording

Demo video URL: [Paste link to screen recording here]

The recording was captured on a physical device ([device model, e.g., iPhone 15 Pro]) and demonstrates:

• App launch and onboarding flow
• [Core feature 1]
• [Core feature 2]
• [Additional flows shown — delete any that don't apply]:
• Account registration, login, and account deletion
• Purchasing/subscribing to paid content
• User-generated content posting, reporting, and blocking
• Permission prompts (location, camera, microphone, contacts, etc.)

2. App Purpose

What problem does this app solve? [Describe the problem your app addresses]

What value does it provide? [Describe the value for your intended audience]

3. Access Instructions & Test Credentials

To review the app's full functionality:

1. [Step-by-step instructions to reach core features] 2. [Any special setup or configuration needed]

Test Account:

• Username: [test_username]
• Password: [test_password]

Note: This account will remain active through [date, at least 2 weeks from submission].

4. External Services

The app uses the following external services:

5. Regional Differences

<!-- Choose one of the following and delete the other -->

Option A — No regional differences: This app functions consistently across all regions with no differences in features or content.

Option B — Regional differences exist: The following features vary by region:

• [Region/Country]: [Description of difference]
• [Region/Country]: [Description of difference]

6. Regulated Industry Documentation (if applicable)

<!-- Delete this section entirely if your app does NOT operate in a regulated industry -->

This app operates in the [industry name] industry. The following documentation is attached or available upon request:

• [License/certification name]: [Details or link]
• [Regulatory approval]: [Details or link]

Rule: Missing Subscription Metadata in App Store Listing

• Guideline: 3.1.2 – Business – Payments – Subscriptions
• Severity: REJECTION
• Category: metadata

What to Check

Apps offering auto-renewable subscriptions must include all of the following in both the app and App Store metadata:

Required in the App

• Title of auto-renewing subscription
• Length of subscription
• Price of subscription (and price per unit if appropriate)
• Functional link to Privacy Policy
• Functional link to Terms of Use (EULA)

Required in App Store Metadata

• Privacy Policy URL — Set in the Privacy Policy field in App Store Connect
• Terms of Use (EULA) — Either:
• A functional link in the App Description, OR
• A custom EULA added in the EULA field in App Store Connect
• If using Apple's standard EULA, include a link to it in the description

How to Detect

Check App Store Connect fields

# Pull canonical metadata JSON
asc metadata pull --app "<APP_ID>" --version "<VERSION>" --dir ./metadata

# Check if version descriptions mention ToS / EULA links
grep -i "terms of use\|terms of service\|terms and conditions\|eula\|end user license" \
  ./metadata/version/<VERSION>/*.json

# Check whether the App Store Connect Privacy Policy URL field is present
grep -i "privacyPolicyUrl" ./metadata/app-info/*.json

Check for URL patterns in descriptions

# Look for actual URLs (http/https links) in descriptions
grep -oE 'https?://[^" ]+' ./metadata/version/<VERSION>/*.json

Check App Store Connect EULA field

In App Store Connect → App Information → scroll to EULA section. Verify a custom EULA is uploaded or the standard Apple EULA is referenced.

Check in-app subscription flow

Verify the app's subscription purchase screen includes:

• Subscription title and duration
• Price
• Tappable Privacy Policy link
• Tappable Terms of Use link
• "Restore Purchases" button

Resolution

1. Add a Terms of Use / EULA link to the app description for every locale 2. Add a Privacy Policy URL in App Store Connect → App Information → Privacy Policy URL 3. Optionally, add a custom EULA in App Store Connect → App Information → EULA 4. Ensure the in-app subscription screen shows all required information with working links

Description Template

Add this block at the bottom of your app description:

Terms of Use: https://yourdomain.com/terms
Privacy Policy: https://yourdomain.com/privacy

Example Rejection

Guideline 3.1.2 - Business - Payments - Subscriptions

>

Issue Description

>

The submission did not include all the required information for apps offering auto-renewable subscriptions.

>

The following information needs to be included in the App Store metadata:

>

- A functional link to the Terms of Use (EULA). If you are using the standard Apple Terms of Use (EULA), include a link to the Terms of Use in the App Description. If you are using a custom EULA, add it in App Store Connect.

>

Next Steps

>

Update the App Store metadata to include the information specified above.

Rule: Missing Privacy Manifest

• Guideline: 5.1.1 – Legal – Privacy (Spring 2024 requirement)
• Severity: REJECTION
• Category: privacy

What to Check

Starting Spring 2024, apps must include a Privacy Manifest (PrivacyInfo.xcprivacy) if they use any of Apple's "Required Reason APIs". Apple will reject apps that use these APIs without declaring the reason.

Required Reason API Categories

What to Declare in the Manifest

• NSPrivacyTracking: Whether the app uses data for tracking (true/false)
• NSPrivacyTrackingDomains: List of tracking domains (if any)
• NSPrivacyCollectedDataTypes: What data types are collected
• NSPrivacyAccessedAPITypes: Required reason APIs used, with reason codes

How to Detect

Check for Privacy Manifest existence

# Look for PrivacyInfo.xcprivacy in the project
find . -name "PrivacyInfo.xcprivacy" -not -path "./.build/*"

Check for Required Reason API usage

# UserDefaults (most common)
grep -rn "UserDefaults\|NSUserDefaults\|standardUserDefaults" --include="*.swift" --include="*.m" .

# File Timestamps
grep -rn "NSFileCreationDate\|NSFileModificationDate\|creationDate\|modificationDate" --include="*.swift" --include="*.m" .

# System Boot Time
grep -rn "systemUptime\|mach_absolute_time\|ProcessInfo.*systemUptime" --include="*.swift" --include="*.m" .

# Disk Space
grep -rn "volumeAvailableCapacity\|statfs\|statvfs" --include="*.swift" --include="*.m" .

Check third-party SDK manifests

Many popular SDKs (Firebase, Analytics, etc.) now bundle their own PrivacyInfo.xcprivacy. Ensure your app's manifest covers APIs used in your own code.

Resolution

1. Create PrivacyInfo.xcprivacy in your Xcode project root 2. Add it to your app target's "Copy Bundle Resources" build phase 3. Declare all Required Reason APIs with appropriate reason codes 4. For Flutter apps, place the manifest in ios/Runner/PrivacyInfo.xcprivacy

Minimal Example

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSPrivacyTracking</key>
    <false/>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>CA92.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

Example Rejection

Your app uses APIs that require a Privacy Manifest. Please add a PrivacyInfo.xcprivacy file to your app that includes the required reason codes for the APIs used by your app.

>

The following APIs require reasons:

- NSPrivacyAccessedAPICategoryUserDefaults

- NSPrivacyAccessedAPICategoryFileTimestamp

Rule: Requiring Unnecessary Personal Data

• Guideline: 5.1.1 – Legal – Privacy – Data Collection and Storage
• Severity: REJECTION
• Category: privacy

What to Check

Apps must only require personal information that is directly relevant to the app's core functionality. If information is useful but not essential, it must be optional.

Commonly Flagged Required Fields

• Phone number — unless the app's core function requires calling/SMS
• Gender — unless medically or fitness-relevant
• Marital status — rarely relevant
• Date of birth — unless age-gating is legally required
• Home address — unless shipping or location-specific services are core

Context Matters

• A fitness app may reasonably require gender (for calorie calculations)
• A dating app may reasonably require age and gender
• A shopping app should NOT require marital status
• A note-taking app should NOT require phone number

How to Detect

Code Inspection

# Find registration/onboarding/profile forms
grep -rn "phone\|gender\|marital\|birthdate\|date.of.birth\|address\|registration\|onboarding\|signup\|sign.up\|profile" --include="*.swift" --include="*.dart" .

# Check if fields are marked as required vs optional
grep -rn "required\|validator\|isRequired\|optional" --include="*.swift" --include="*.dart" .

UI Inspection

1. Run the app and complete the onboarding/registration flow 2. For each personal data field, check:

• Is it required (blocks progress if empty)?
• Is it relevant to the app's core feature?

3. Flag any required field that isn't directly relevant to what the app does

Resolution

1. Make non-essential personal data fields optional (remove validation requirements) 2. Add "Skip" or "Not now" options for optional profile information 3. If collecting data for personalization, clearly explain why and make it opt-in 4. Review the App Privacy label in App Store Connect to ensure it matches what you actually collect

Example Rejection

Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage

>

Issue Description

>

The app requires users to provide personal information that is not directly relevant to the app's core functionality.

>

Apps should only require users to provide information that is necessary for the app to function. If information is useful for a non-essential feature, apps may request the information but make it optional.

>

Next Steps

>

Update the app to not require users to provide the following personal information:

>

- Phone number

- Gender

Rule: Misleading Subscription Pricing Display

• Guideline: 3.1.2 – Business – Payments – Subscriptions
• Severity: REJECTION
• Category: subscription

What to Check

The subscription purchase flow must display the actual billed amount as the most prominent pricing element. Calculated/derived pricing (e.g., "only $2.50/month" for an annual plan billed at $29.99/year) must be subordinate in:

• Font size
• Font weight
• Color contrast
• Position/layout

Common Violations

• Showing "$2.50/mo" in large bold text while "$29.99/year" is in small gray text
• Using a bright accent color for the calculated monthly price but muted text for the real billed amount
• Placing the per-month breakdown above or more prominently than the actual charge
• Free trial text overshadowing the post-trial billed price

How to Detect

Code Inspection

# Find subscription UI code
grep -rn "paywall\|subscribe\|pricing\|subscription" --include="*.swift" --include="*.dart" .

# Look for calculated pricing patterns
grep -rn "perMonth\|per_month\|monthly.*price\|price.*month\|calculated\|divided" --include="*.swift" --include="*.dart" .

Visual Inspection

1. Run the app and navigate to the subscription purchase screen 2. Compare the visual hierarchy of:

• The calculated price (per month/week breakdown)
• The actual billed amount (what Apple will charge)
• Free trial or introductory pricing text

3. The billed amount must be the largest, boldest, most visible price

Checklist

• [ ] Billed amount uses the largest font size among all pricing elements
• [ ] Billed amount has the highest contrast color
• [ ] Billed amount is positioned prominently (not buried below other pricing)
• [ ] Calculated/broken-down pricing uses smaller, lighter text
• [ ] Free trial terms do not overshadow the post-trial price

Resolution

1. Make the total billed amount the most prominent pricing text 2. Show calculated pricing (per month / per week) in smaller, subordinate text 3. Ensure free trial duration is visible but does not overshadow the billing amount 4. Follow Apple HIG guidance for subscription purchase flows

Example Rejection

Guideline 3.1.2 - Business - Payments - Subscriptions

>

One or more auto-renewable subscriptions are marketed in the purchase flow in a way that may mislead or confuse users about the subscription terms or pricing. Specifically:

>

- The auto-renewable subscription displays the monthly calculated pricing for the subscription more clearly and conspicuously than the billed amount.

>

Next Steps

>

To resolve this issue, it would be appropriate to:

>

- Revise the auto-renewable subscription purchase flow to ensure that the billed amount is the most clear and conspicuous pricing element in the layout. Any other pricing elements, including free trial, introductory pricing, and calculated pricing information, must be displayed in a subordinate position and size to the total billed amount.

Rule: Missing Terms of Use and Privacy Policy for Subscriptions

• Guideline: 3.1.2 – Business – Payments – Subscriptions
• Severity: REJECTION
• Category: subscription

What to Check

The in-app subscription purchase flow and the app itself must include:

1. Title of the auto-renewing subscription 2. Length of subscription (e.g., 1 month, 1 year) 3. Price of subscription (and price per unit if appropriate) 4. Functional link to Privacy Policy 5. Functional link to Terms of Use (EULA)

And the App Store metadata must include:

• Privacy Policy URL in the Privacy Policy field in App Store Connect
• Terms of Use (EULA) link in either the app description or the EULA field

How to Detect

Check in-app subscription screens

Search the codebase for subscription paywall / purchase views:

# Find subscription-related UI files
grep -rn "subscribe\|paywall\|purchase\|StoreKit\|RevenueCat\|Superwall" --include="*.swift" --include="*.dart" .

# Check if terms/privacy links exist in those files
grep -rn "terms\|privacy\|eula\|TermsOfService\|PrivacyPolicy" --include="*.swift" --include="*.dart" .

Check metadata descriptions

# Verify ToS / EULA links in pulled version metadata
grep -i "terms\|privacy\|eula" ./metadata/version/<VERSION>/*.json

# Verify the App Store Connect Privacy Policy URL field is present
grep -i "privacyPolicyUrl" ./metadata/app-info/*.json

Check App Store Connect

• App Information → Privacy Policy URL field must not be empty
• App Information → EULA field should have custom EULA or description should reference Apple's standard EULA

Resolution

1. Add tappable Terms of Use and Privacy Policy links to every subscription paywall screen 2. Add links to the app description in all locales 3. Set the Privacy Policy URL field in App Store Connect 4. If using a custom EULA, upload it in the EULA field

Example Rejection

Guideline 3.1.2 - Business - Payments - Subscriptions

>

The submission did not include all the required information for apps offering auto-renewable subscriptions.

>

The following information needs to be included in the App Store metadata:

>

- A functional link to the Terms of Use (EULA). If you are using the standard Apple Terms of Use (EULA), include a link to the Terms of Use in the App Description. If you are using a custom EULA, add it in App Store Connect.