Run ALL App Store readiness checks on an iOS project and return a single prioritized report: privacy manifest vs required-reason API usage, Info.plist usage-description keys, third-party SDK privacy manifests, and placeholder/test-credential traps. Start here — it answers 'is this app ready to submit?'.

Compare the required-reason APIs actually used in first-party code against what the app's PrivacyInfo.xcprivacy declares. Reports undeclared categories (hard rejects), invalid reason codes, and a missing manifest.

Detect which permission-gated capabilities (camera, location, photos, mic, contacts, tracking, etc.) the project uses, then verify Info.plist has the required NS…UsageDescription purpose string for each. Missing keys crash the app and fail review.

Scan CocoaPods dependencies for SDKs on Apple's required-privacy-manifest list that ship WITHOUT a PrivacyInfo.xcprivacy. Those are hard rejects at upload time.

Look for placeholder or public TEST credentials left in Info.plist (e.g. Google's sample AdMob App ID) that must never ship to production.

Check the App Store legal-link requirements: a Privacy Policy link (mandatory for every app) and, for apps with in-app purchases, a Terms of Use (EULA) link — required both at the point of purchase and in the App Store Connect description text (Guideline 3.1.2). Also flags the in-app account-deletion requirement (5.1.1(v)) when account creation is detected.

For apps with accounts: flags a missing demo account for App Review (2.1), the in-app account-deletion requirement (5.1.1(v)), and third-party/social login shipped without Sign in with Apple (4.8).

Detect non-Apple payment rails (Stripe, PayPal, Braintree, Paddle…) in a project that has no StoreKit. Charging for digital content outside Apple's IAP is Guideline 3.1.1 — a hard reject. Physical goods are exempt, so this reports for judgement rather than asserting a violation.

Cross-check every UIBackgroundModes entry in Info.plist against actual API usage in source. Declaring a background mode the app doesn't implement is Guideline 2.5.4, and reviewers check it specifically.

Scan source and Info.plist for content that should never reach review: lorem ipsum, Stripe test keys, YOUR_API_KEY-style template tokens, example.com dead links, and template app names still set as CFBundleDisplayName (Guideline 2.1).

Generate a valid PrivacyInfo.xcprivacy covering every required-reason API detected in first-party code (plus anything already declared). By default only PREVIEWS the XML; pass write=true to save it to the app target directory. After writing, the file still must be added to the app target in Xcode.

Apply the safe, unambiguous App Store fixes automatically: add ITSAppUsesNonExemptEncryption=false, (re)generate PrivacyInfo.xcprivacy to cover detected required-reason APIs, and (optionally) insert stub NS…UsageDescription strings. Anything a machine shouldn't guess (real AdMob ID, missing icon, UIWebView, dependency updates) is reported as manual follow-up. Modifies files on disk.

List the apps on your App Store Connect account (id, name, bundle id). Requires ASC_KEY_ID, ASC_ISSUER_ID, and ASC_PRIVATE_KEY(_PATH) env vars. Use the returned app id with asc_get_rejections.

Fetch recent App Store review rejections for an app and map any referenced Review Guideline numbers to plain-language summaries and typical fixes. This closes the loop from 'why was I rejected' to 'here's what to change'.

Check the App Store Connect side of readiness for the next version: whether demo credentials are actually filled in for a login-gated app (Guideline 2.1 — the most common avoidable rejection), whether App Review notes exist, and whether the required iPhone screenshot sets have anything in them. Complements the local preflight, which can only see the binary.

Explain an App Store Review Guideline number (e.g. '5.1.1') in plain language with a typical fix. Works offline — no credentials needed.