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
.
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:
- for subscriptions or IAP
- for UGC or moderation-heavy apps
- for Kids Category
- for health, fitness, or medical claims
- for games
- for AI or LLM features
- for crypto, trading, or financial workflows
- for VPN and networking apps
- 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:
- for Capacitor, auth, analytics, subscription, and SDK dependencies
- for app identifiers, app name, web asset config, and live update settings
- or the project-specific
- any files
- if present
- 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 , 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
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:
markdown
## 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 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 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.