Capacitor Apple Review Preflight

Capacitor Apple Review Preflight

Run a pre-submission or post-rejection Apple review audit for a Capacitor app.

This skill adapts the Apple guideline and rejection-rule corpus from truongduy2611/app-store-preflight-skills and narrows the workflow to Capacitor-specific project inspection.

When to Use This Skill

• User wants an Apple App Store review preflight for a Capacitor app
• User received an Apple rejection and wants the project audited against likely guideline failures
• User wants to check metadata, entitlements, privacy manifests, Sign in with Apple, subscriptions, or minimum functionality before submission
• User wants reviewer-notes guidance for a Capacitor iOS submission

Live Project Snapshot

Detected Capacitor, auth, subscription, analytics, and privacy-related packages: !node -e "const fs=require('fs');if(!fs.existsSync('package.json'))process.exit(0);const pkg=JSON.parse(fs.readFileSync('package.json','utf8'));const sections=['dependencies','devDependencies'];const out=[];for(const section of sections){for(const [name,version] of Object.entries(pkg[section]||{})){if(name.startsWith('@capacitor/')||name.startsWith('@capgo/')||name.includes('firebase')||name.includes('sentry')||name.includes('revenuecat')||name.includes('purchase')||name.includes('subscription')||name.includes('auth')||name.includes('analytics')||name.includes('segment')||name.includes('amplitude')||name.includes('mixpanel'))out.push(section+'.'+name+'='+version)}}console.log(out.sort().join('\n'))"

Relevant Apple review file paths: !find . -maxdepth 6 \( -name 'package.json' -o -name 'capacitor.config.json' -o -name 'capacitor.config.ts' -o -name 'capacitor.config.js' -o -name 'Info.plist' -o -name '*.entitlements' -o -name 'PrivacyInfo.xcprivacy' -o -name 'project.pbxproj' -o -path './ios' -o -path './fastlane/metadata' -o -path './metadata' \)

Procedure

Step 1: Confirm This Is the Right Review Scope

Use this skill for Apple-facing review work, not for generic publishing.

If the task is mostly about screenshots, release setup, or store upload mechanics, combine this skill with capacitor-app-store.

Step 2: Identify App Type and Load the Right Checklist

Always read:

• references/guidelines/by-app-type/all_apps.md

Then add the checklist that matches the app:

• subscription_iap.md for subscriptions or IAP
• social_ugc.md for UGC or moderation-heavy apps
• kids.md for Kids Category
• health_fitness.md for health, fitness, or medical claims
• games.md for games
• ai_apps.md for AI or LLM features
• crypto_finance.md for crypto, trading, or financial workflows
• vpn.md for VPN and networking apps
• macos.md only when the submission also targets macOS

Use references/guidelines/README.md for the full guideline index when a rejection cites a specific section.

Step 3: Inspect Capacitor and iOS Project State

Start from the injected snapshot above, then inspect:

• package.json for Capacitor, auth, analytics, subscription, and SDK dependencies
• capacitor.config.* for app identifiers, app name, web asset config, and live update settings
• ios/App/App/Info.plist or the project-specific Info.plist
• any *.entitlements files
• PrivacyInfo.xcprivacy if present
• fastlane/metadata or other local metadata directories if they exist

Pay special attention to Capacitor-specific Apple review risks:

• social login providers without a Sign in with Apple path when required
• heavy WebView-only apps that may trigger 4.2 minimum functionality concerns
• third-party SDKs that imply Required Reason API declarations or privacy disclosures
• native capabilities enabled in Xcode but not justified by shipped functionality
• Capgo, Appflow, or other live-update flows that need clear reviewer notes and compliance boundaries
• missing or vague usage strings for camera, photo library, microphone, location, notifications, Face ID, tracking, or local network access

Step 4: Run Rule-Based Review Passes

Use the upstream rule files as the source of truth:

• metadata: references/rules/metadata/*.md
• subscription: references/rules/subscription/*.md
• privacy: references/rules/privacy/*.md
• design: references/rules/design/*.md
• entitlements: references/rules/entitlements/*.md

Map them onto the Capacitor app:

• metadata rules against App Store text, screenshots, preview videos, and review notes
• privacy rules against Info.plist, privacy manifests, SDK usage, and data collection flows
• design rules against app navigation, native value, login flows, and reviewer accessibility
• entitlements rules against enabled capabilities in the iOS project

If App Store metadata is not stored locally and asc is available, pull it with asc metadata pull --output-dir ./metadata. If not, audit local metadata sources and state what remains unverified.

Step 5: Produce a Capacitor-Focused Preflight Report

Use this format:

## Apple Review Preflight

### Rejections Found
- [GUIDELINE X.X.X] Issue summary
  - Evidence: file or metadata location
  - Why it matters for this Capacitor app
  - Fix: exact remediation

### Warnings
- [GUIDELINE X.X.X] Potential issue

### Passed
- [Category] Checks that looked clean

### Missing Inputs
- Metadata or review assets that were not available locally

Order findings by severity and make each fix concrete.

Step 6: Suggest Reviewer Notes and Submission Follow-Ups

When relevant, draft reviewer notes for:

• demo accounts or test credentials
• hidden or non-obvious features
• hardware dependencies
• subscription test flows
• AI moderation or content controls
• live-update behavior and what code can change post-review
• reasons for special entitlements or network behavior

Error Handling

• If app metadata is unavailable locally and asc is not configured, continue with the code and project audit and clearly mark metadata checks as partial.
• If the app is mostly a thin web wrapper, call out guideline 4.2 risk directly rather than burying it in warnings.
• If social login is present, verify whether guideline 4.8 requires Sign in with Apple before concluding the auth flow is review-safe.
• If third-party SDKs suggest Required Reason API usage, inspect PrivacyInfo.xcprivacy before assuming privacy compliance.
• If the user is asking how to fix a specific rejection, prioritize the cited guideline and only then expand to adjacent risks.

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.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 --output-dir ./metadata
cat ./metadata/en-US/description.txt | 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
find . -name "*.entitlements" -not -path "./.build/*" -exec plutil -p {} \;
# or
find . -name "*.entitlements" -not -path "./.build/*" -exec cat {} \;

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 assets
asc screenshots list --app-id <YOUR_APP_ID> --type previews

Automated Check (ffmpeg frame analysis)

# Extract first frame of each preview for visual inspection
for preview in ./previews/*.mp4; do
  ffmpeg -i "$preview" -vframes 1 -q:v 2 "${preview%.mp4}_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
cat ./metadata/*/name.txt ./metadata/*/subtitle.txt 2>/dev/null | \
  grep -i "iphone\|ipad\|macbook\|apple watch\|apple tv\|imessage\|facetime\|siri\|icloud\|vision pro"

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/

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 metadata for all locales
asc metadata pull --output-dir ./metadata

# Check Chinese locale specifically
grep -ri "chatgpt\|openai\|gpt-4\|gemini\|claude\|anthropic\|midjourney\|dall-e\|copilot\|bard" ./metadata/zh-Hans/

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/

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 metadata first
asc metadata pull --output-dir ./metadata

# Search across all locales
grep -ri "android\|google play\|samsung\|huawei\|apk\|amazon appstore\|windows store\|microsoft store" ./metadata/

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 --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: 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 metadata
asc metadata pull --output-dir ./metadata

# Check if description contains ToS/EULA link
grep -i "terms of use\|terms of service\|terms and conditions\|eula\|end user license" ./metadata/*/description.txt

# Check if description contains Privacy Policy link
grep -i "privacy policy\|privacy" ./metadata/*/description.txt

Check for URL patterns in descriptions

# Look for actual URLs (http/https links) in descriptions
grep -oE "https?://[^ ]+" ./metadata/*/description.txt

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" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" --include="*.vue" --include="*.svelte" .

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

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/PP links in descriptions
grep -i "terms\|privacy\|eula" ./metadata/*/description.txt

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.