App Store Submission Reference

Overview

Complete reference for every App Store submission requirement:

• Part 1 — Required metadata fields (descriptions, screenshots, keywords, App Review info)
• Part 2 — Privacy requirements (manifest schema, nutrition labels, ATT, Required Reason APIs)
• Part 3 — App Review Guidelines quick reference (all sections 1-5)
• Part 4 — Age rating system (5-tier, capabilities, regional variations)
• Part 5 — Export compliance (encryption decision tree)
• Part 6 — Account and authentication requirements (deletion, SIWA)
• Part 7 — Monetization and IAP submission pipeline
• Part 8 — EU-specific compliance (DSA trader status)
• Part 9 — Build upload and processing
• Part 10 — WWDC25 changes (draft submissions, accessibility labels, tags)

When to Use This Skill

Use when

• Looking up specific metadata field requirements or character limits
• Checking App Review guideline numbers for a specific topic
• Verifying privacy manifest schema fields or Required Reason API categories
• Understanding age rating tiers and new capability declarations
• Checking EU compliance requirements for DSA trader status
• Understanding IAP submission pipeline and review flow
• Preparing builds for upload (SDK requirements, encryption, signing)

Do NOT use when

• Deciding if your app is ready to submit (use app-store-submission)
• Troubleshooting a rejection (use app-store-diag)
• Implementing in-app purchases (use storekit-ref)
• Writing privacy manifest code (use privacy-ux)
• Auditing accessibility compliance (use accessibility-diag)

Related Skills

• app-store-submission — Discipline skill with pre-flight checklist and workflow
• app-store-diag — Rejection troubleshooting and appeal guidance
• privacy-ux — Privacy manifest implementation, ATT UX, permission requests
• storekit-ref — StoreKit 2 API reference for IAP implementation
• accessibility-diag — Accessibility compliance scanning and VoiceOver testing

Key Terminology

Part 1: Required Metadata Fields

App Information

Visual Assets

Screenshot Requirements

Screenshots must be provided for each device size you support:

Screenshots must show the app in actual use. Not permitted: title art alone, login screens, splash screens, or screens from other platforms.

App Preview Video Specifications

App Icon Requirements

App Review Information

Metadata Rules (Guideline 2.3)

• App names must be unique, max 30 characters
• Keywords must not include trademarked terms, popular app names, or pricing terms ("free", "sale")
• Screenshots must show the app in use, not just marketing art
• Icons, screenshots, and previews must be appropriate for a 4+ rating even if the app is rated higher
• "For Kids" and "For Children" are reserved for the Kids category
• No other mobile platform names or imagery in screenshots (no Android phones, Windows logos)
• Metadata must accurately reflect app functionality; misleading metadata is grounds for rejection

Localization Requirements

When localizing, provide screenshots that match the localized UI. Reviewers check that screenshots accurately represent the app in each locale.

Category Selection

Available categories: Books, Business, Developer Tools, Education, Entertainment, Finance, Food & Drink, Games, Graphics & Design, Health & Fitness, Lifestyle, Magazines & Newspapers, Medical, Music, Navigation, News, Photo & Video, Productivity, Reference, Shopping, Social Networking, Sports, Travel, Utilities, Weather.

Part 2: Privacy Requirements

Privacy Policy (Guideline 5.1.1(i))

Required in BOTH locations:

1. App Store Connect metadata (Privacy Policy URL field)
2. Within the app itself (accessible from settings or equivalent)

The privacy policy must identify:

• What data is collected and by what means
• All uses of collected data
• Third-party sharing practices
• Data retention and deletion policies
• How users can revoke consent

Privacy Manifest Schema (PrivacyInfo.xcprivacy)

<!-- Top-level keys -->
NSPrivacyTracking              <!-- Boolean: Does app track users? -->
NSPrivacyTrackingDomains       <!-- Array<String>: Domains used for tracking -->
NSPrivacyCollectedDataTypes    <!-- Array<Dictionary>: Data collected -->
NSPrivacyAccessedAPITypes      <!-- Array<Dictionary>: Required Reason APIs -->

NSPrivacyCollectedDataTypes Entry

Each dictionary in the array contains:

NSPrivacyAccessedAPITypes Entry

Each dictionary in the array contains:

Complete PrivacyInfo.xcprivacy 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>NSPrivacyTrackingDomains</key>
    <array/>
    <key>NSPrivacyCollectedDataTypes</key>
    <array>
        <dict>
            <key>NSPrivacyCollectedDataType</key>
            <string>NSPrivacyCollectedDataTypeEmailAddress</string>
            <key>NSPrivacyCollectedDataTypeLinked</key>
            <true/>
            <key>NSPrivacyCollectedDataTypeTracking</key>
            <false/>
            <key>NSPrivacyCollectedDataTypePurposes</key>
            <array>
                <string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
            </array>
        </dict>
    </array>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>CA92.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

API Category Identifiers

Generating Aggregate Privacy Report

Xcode > Product > Archive > Generate Privacy Report

This produces a PDF summarizing privacy manifests from your app and all embedded frameworks.

Required Reason API Categories

App Privacy Details (Nutrition Labels)

Data Type Categories

Purpose Categories

Tracking and Collection Definitions

"Collected" means data is transmitted off-device and accessible beyond what is needed to service the current request. On-device-only processing is NOT collection.

"Tracking" means:

• Linking user/device data from your app with third-party data for advertising or measurement, OR
• Sharing user/device data with a data broker

App Tracking Transparency (ATT)

Required if your app "tracks" per Apple's definition above.

• Add NSUserTrackingUsageDescription to Info.plist (explains why tracking is needed)
• Call ATTrackingManager.requestTrackingAuthorization() before tracking
• Respect the result:
  • .authorized — User granted permission to track
  • .denied — User denied tracking; do not track
  • .notDetermined — User has not yet been asked
  • .restricted — Device-level restriction prevents tracking

Request at a contextually appropriate moment, not at first launch.

Common Purpose Strings (NS*UsageDescription)

These Info.plist keys must be present for each system permission your app requests:

Missing purpose strings cause immediate rejection. Purpose string text must clearly explain why the permission is needed in the context of your app's functionality.

Third-Party SDK Privacy Manifests

Apple maintains a list of commonly used SDKs that require privacy manifests. Starting spring 2024, if your app includes these SDKs without privacy manifests, it will be flagged during submission.

Third-party SDKs should include their own PrivacyInfo.xcprivacy in their framework bundle. The aggregate privacy report combines all manifests from your app and embedded frameworks.

If a third-party SDK does not include a privacy manifest, you must declare its data collection in your app's privacy manifest.

Part 3: App Review Guidelines Quick Reference

For the complete guideline index (Sections 1-5), see references/app-review-guidelines.md.

Most Common Rejection Reasons

Based on Apple's published data, the most frequent rejection reasons:

App Review Timeline

Review times increase during holidays and major iOS release periods. Plan submissions accordingly.

Part 4: Age Rating System

Five-Tier Rating System (Updated January 31, 2026)

Capability Declarations (New, WWDC25)

Apps must declare if they include these capabilities:

These declarations appear alongside the age rating on the App Store product page, giving parents and users additional transparency.

Regional Variations

Age ratings map differently across regions:

The age rating questionnaire automatically generates the appropriate regional ratings based on your answers.

Age Rating Best Practices

• Answer the questionnaire conservatively; under-rating leads to rejection
• If your app accesses unrestricted web content (WebView without content filter), it will be rated 16+ minimum
• UGC apps typically need 13+ minimum due to moderation requirements
• Simulated gambling (even without real money) requires at least 9+
• Realistic violence in gameplay requires at least 13+

Age Rating Questionnaire Topics

The questionnaire covers these content categories:

The system automatically calculates your app's age rating across all regions based on your answers.

Part 5: Export Compliance

Encryption Decision Tree

Does your app use encryption?
├── No → Set ITSAppUsesNonExemptEncryption = NO in Info.plist → Done
├── Only HTTPS/TLS/URLSession?
│   ├── Yes → Exempt, set ITSAppUsesNonExemptEncryption = NO → Done
│   │         (May need annual self-classification report to BIS)
│   └── No (custom encryption) →
│       Set ITSAppUsesNonExemptEncryption = YES →
│       Upload compliance documentation to App Store Connect →
│       Receive encryption compliance code →
│       Set ITSEncryptionExportComplianceCode in Info.plist → Done

Info.plist Keys

<!-- Most apps: HTTPS only -->
<key>ITSAppUsesNonExemptEncryption</key>
<false/>

<!-- Apps with custom encryption -->
<key>ITSAppUsesNonExemptEncryption</key>
<true/>
<key>ITSEncryptionExportComplianceCode</key>
<string>YOUR_COMPLIANCE_CODE</string>

Exempt Encryption Uses

These are exempt from export documentation (but may still require annual self-classification):

• HTTPS/TLS (URLSession, Network.framework, WKWebView)
• Secure Enclave operations (biometric auth, Keychain)
• Apple's built-in encryption frameworks (CryptoKit, Security.framework) when used per Apple documentation
• Password hashing (bcrypt, scrypt, PBKDF2)

Non-Exempt Encryption Uses

These require compliance documentation:

• Custom encryption algorithms
• Open-source encryption libraries (OpenSSL, libsodium) used for non-standard purposes
• End-to-end encrypted messaging
• VPN implementations
• Custom DRM systems

Part 6: Account and Authentication

Account Deletion (Required Since June 2022)

Apps that support account creation must offer account deletion. Requirements:

Sign in with Apple Token Revocation

// Server-side: revoke SIWA tokens when account deleted
// POST https://appleid.apple.com/auth/revoke
// Parameters: client_id, client_secret, token, token_type_hint

Failing to revoke SIWA tokens during account deletion is a common rejection reason.

Sign in with Apple (Guideline 4.8)

Required when: Your app offers ANY third-party or social login option (Google, Facebook, Twitter, email/password via third-party provider).

Exceptions — SIWA not required when

• App is for company employees only (internal enterprise app)
• App is for education or enterprise with existing institutional auth
• App uses government or industry-backed citizen ID systems
• App is a client for a specific third-party service (e.g., Gmail app, Slack)

When SIWA is required, it must be offered as an equally prominent option alongside other sign-in methods. It cannot be hidden or given less visual weight.

Account Deletion Implementation Checklist

Apple specifically rejects apps that:

• Require users to call a phone number to delete their account
• Require users to send an email to request deletion
• Only offer account deactivation (hiding profile) instead of full deletion
• Don't handle SIWA token revocation

Part 7: Monetization and IAP

IAP Submission Pipeline

In-app purchases have a separate review process from app submissions:

Required IAP Metadata

IAP Status Flow

Missing Metadata → Ready to Submit → Waiting for Review → In Review → Approved
                                                                    → Rejected

IAP must be in "Ready to Submit" status before it can be included in an app submission.

Subscription Rules (Guideline 3.1.2)

Loot Boxes (Guideline 3.1.1)

Apps offering loot boxes or random item mechanics must disclose the odds of receiving each type of item before purchase.

External Payment Eligibility

Apps in these categories may accept payment outside the IAP system.

Subscription Group Architecture

Subscription Pricing

Subscription Restore Purchases

All subscription apps must implement Restore Purchases functionality. This is tested during App Review. Implement via:

try await AppStore.sync()

If Restore Purchases is missing or non-functional, the app will be rejected.

Free Trial Best Practices

Part 8: EU-Specific Compliance

Digital Services Act (DSA) Trader Status

Applies to: ALL apps distributed in the EU (27 member states)

Timeline: Since February 17, 2025, apps without declared trader status are subject to removal from the EU App Store.

What is Trader Status?

A self-assessment: are you acting as a "trader" (selling goods/services to EU consumers) or a non-trader (hobby, open-source, non-commercial)? Apple cannot determine this for you.

Trader Requirements

If you declare as a trader, you must provide:

This contact information is displayed on your EU product page.

Declaring in App Store Connect

App Store Connect > Users and Access > Developer Profile > Trader Status

Select your trader status for each app. If you have both paid and free apps, each app may have a different trader classification.

EU Alternative Distribution

Under the Digital Markets Act (DMA), Apple allows alternative app distribution in the EU:

• Alternative app marketplaces
• Web distribution (notarized apps)
• Alternative payment processing

These require separate business terms (Alternative Terms Addendum) and additional compliance steps. See Apple's EU developer documentation for details.

EU 27 Member States

Apps distributed in any of these territories require DSA compliance:

Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden.

If your app is available in "All Territories" (the default), it is available in the EU and DSA compliance is required.

Part 9: Build Upload and Processing

Upload Methods

Build Identifiers

Build Selection

• Only one build can be selected per version
• Build selection can be changed until the version is submitted for review
• "Missing Compliance" status blocks build selection until export compliance questions are answered

SDK Requirements

Apps built with outdated SDKs will be rejected after the effective date for new submissions. Existing apps on the store are not affected until they submit an update.

Build Processing

After upload, Apple processes your build:

1. Upload — Binary transferred to Apple (5-30 minutes depending on size)
2. Processing — Apple validates binary, runs automated checks (15-60 minutes)
3. Available — Build appears in App Store Connect, ready for TestFlight or submission
4. Email notification — Sent when processing completes or fails

Common processing failures:

• Missing required architectures (arm64 required)
• Invalid provisioning profile or signing identity
• Missing privacy manifest for third-party SDKs on Apple's list
• Info.plist missing required keys
• Binary too large (OTA download limit: 200 MB over cellular)

IPv6 Compatibility

All apps must work on IPv6-only networks. Apple's review environment uses IPv6. Common issues:

• Hard-coded IPv4 addresses
• Using low-level socket APIs instead of high-level networking
• Third-party SDKs with IPv4-only code

Use URLSession or Network.framework to ensure IPv6 compatibility automatically.

App Thinning and Bitcode

Entitlements and Capabilities

Certain features require entitlements configured in Xcode and provisioning profiles:

TestFlight Submission

TestFlight builds also go through a review process, though lighter than App Store:

Part 10: WWDC25 Changes

Draft Submissions (WWDC 2025-328)

Group multiple items into a single draft submission:

• App version + new IAPs + product page changes
• Review everything together instead of separate submissions
• Draft state: prepare items over time, submit when ready

Reusable Build Numbers on Failure

When a build is rejected due to metadata issues (not binary issues), you can reuse the same build without re-uploading. Previously, rejected builds required a new build string.

Builds Retained After Error Rejection

Builds are no longer removed from App Store Connect after certain rejection types. You can fix metadata issues and resubmit with the same build.

Accessibility Nutrition Labels

New App Store metadata for accessibility features:

• Declare which accessibility features your app supports
• Displayed on your App Store product page
• Categories include VoiceOver support, Dynamic Type, Switch Control, etc.
• Helps users find apps that meet their accessibility needs

App Store Tags (LLM-Generated, Editable)

Apple generates descriptive tags for your app using AI:

• Tags appear on your product page
• You can review and edit suggested tags
• Tags improve discoverability in search
• Based on app metadata, description, and functionality

Custom Product Page Keywords

Product pages can now have unique keywords:

• Different keywords per custom product page
• Improves targeting for different audiences
• Each custom page can appear in different search results

Offer Codes Expanded

Offer codes now support all IAP types:

• Consumables
• Non-consumables
• Non-renewing subscriptions
• Auto-renewable subscriptions (existing)

Review Summaries (AI-Generated)

Apple generates AI summaries of user reviews:

• Summarizes common themes across reviews
• Displayed on the product page
• Updated as new reviews come in
• Helps users quickly understand app quality and common feedback

Analytics Enhancements

100+ new analytics metrics including:

• Pre-order conversion funnels
• Custom product page performance comparison
• Subscription lifecycle metrics (trial to paid conversion, churn timing)
• Peer group benchmarking (compare performance against similar apps)
• Download source attribution refinements

Age Rating Overhaul

Five-tier system with new capability declarations (see Part 4 for full details).

Custom Product Pages (Existing, Enhanced in WWDC25)

Custom product pages allow different App Store presentations for different audiences:

App Store Pricing Changes

Expert Review Checklist

For the comprehensive 9-section submission checklist, see references/expert-review-checklist.md. For the discipline-focused pre-flight workflow, see app-store-submission.

Troubleshooting

10 Common Submission Issues

Expedited Review

Request via App Store Connect when:

• Critical bug fix affecting many users
• Security vulnerability patch
• Time-sensitive event (holiday sale, product launch)
• Legal or government compliance deadline

Apple reviews expedited requests case-by-case. Not guaranteed. Provide clear justification.

Rejection Response Options

Resolution Center Best Practices

• Respond within 14 days (submissions auto-expire after that)
• Be specific about what you changed to address the rejection
• Include screenshots if the fix is visual
• Reference specific guideline numbers when explaining compliance
• If appealing, provide factual evidence, not emotional arguments

App Store Connect API for Submissions

For automated submission workflows:

Authentication requires an API key from App Store Connect (Users and Access > Integrations > App Store Connect API).

Pre-Submission Testing Checklist

Resources

WWDC: 2022-10166, 2025-224, 2025-241, 2025-252, 2025-328

Docs: /app-store/review/guidelines, /app-store/submitting, /app-store/app-privacy-details, /help/app-store-connect

Skills: app-store-submission, app-store-diag, privacy-ux, storekit-ref, accessibility-diag