Submitting an iOS app is a chain of connected records: bundle ID, signing, App Store Connect app, build, version metadata, privacy disclosures, compliance, review access, and release controls. Most avoidable delays come from disagreement between those records or from a reviewer who cannot reach the feature being reviewed. Work through this list using the exact archive intended for release.
Submission gates
Make the binary, listing, and reviewer path tell the same story
Release build
Signing, capabilities, privacy manifests, purchases, and core flows are production-ready.
App record
Metadata, screenshots, URLs, privacy, age rating, and pricing match the build.
Review path
Credentials and instructions work, submission is complete, and release control is intentional.
1. Verify agreements, roles, and identifiers
- Apple Developer Program membership is active.
- Required agreements, tax forms, and banking details are accepted where applicable.
- The App ID and bundle ID exactly match the release target.
- Entitlements and capabilities are enabled in both the developer account and Xcode project.
- The submitting team member has the necessary App Store Connect role.
Do this before archiving. A last-minute identifier or entitlement change can require new provisioning and another test cycle.
2. Create or audit the App Store Connect record
Confirm the app name, primary language, bundle ID, SKU, category, content rights, and availability. The name must be between 2 and 30 characters. Add the Support URL, and provide a Privacy Policy URL for iOS apps. Check that the seller name and copyright are correct because some identity fields are not casual release-time edits.
Use Apple's current App information reference and our metadata limits reference while completing the record.
3. Prepare the release archive
Increment the version and build number, archive with the release configuration, and validate before upload. Confirm distribution signing, production endpoints, capabilities, privacy manifests, required-reason API declarations, third-party SDK versions, and export-compliance behavior. Remove debug logging, sample accounts, staging URLs, and development menus.
- Test a clean install and upgrade from the current public version.
- Test purchases, subscriptions, restores, sign-in, deep links, push notifications, and account deletion.
- Verify accessibility labels and permission prompts.
- Test on the oldest supported OS and representative devices.
- Inspect crash reporting and backend observability for release identifiers.
4. Upload and wait for build processing
Upload through Xcode, Transporter, or your CI/CD pipeline. Wait until processing completes, then resolve compliance questions and confirm the build is selectable for the intended version. A successful upload is not a successful submission; the processed build still needs to be attached to the App Store version.
5. Complete version metadata and creative
Add the subtitle, description, keywords, promotional text, What's New text for updates, and the correct build. Upload screenshots for each required device-size set and localization. Apple supports one to ten screenshots per screenshot set and up to three app previews per localization and device size. Verify the exact current requirements in Apple's screenshot and preview documentation.
Do not let creative outrun the build. Screenshots must represent the product being submitted, and claims should be demonstrable during review. Use the screenshot best practices guide to review order, readability, and localization.
6. Complete privacy, age rating, and compliance
Audit first-party code and every SDK before answering App Privacy questions. Disclose collected data, linked data, tracking, and purposes accurately. Ensure the public privacy policy agrees with the in-app behavior and includes required account-deletion information. Complete the current age-rating questionnaire based on the app's content and features.
For encryption, answer App Store Connect's export-compliance questions and upload documentation when required. Apple explains that each build may need a determination unless the appropriate information is configured in the app's Info.plist. See Apple's export compliance overview.
7. Configure pricing, availability, and release method
Confirm price, countries or regions, tax category, pre-order state if used, and app distribution method. For subscriptions and in-app purchases, verify product status, localization, screenshots for review, pricing, and the association with the app version when first submitted. Choose the release method intentionally: automatic, manual, or a scheduled option supported by the current workflow.
8. Give App Review a reproducible path
Provide a real contact who can respond during review. If sign-in is required, Apple requests an active, non-expiring demo account. Include numbered steps for hidden or role-gated features, explain special hardware and location needs, and provide sample data when an empty account would make the app unusable.
- Test credentials from a clean device and network.
- Avoid one-time codes tied to a team member's phone.
- Explain subscription state and how to reach purchase flows.
- Document features controlled by remote configuration.
- Use Review notes for operational instructions, not promotional copy.
Apple's App Review page specifically asks developers to include settings, user accounts, or special instructions needed for review.
9. Add for Review, then Submit for Review
This two-step behavior causes real confusion. Select the build, resolve required fields, and click Add for Review. Then open the submission and click Submit for Review. Apple explicitly notes that items are not sent to App Review until the second action is completed. Follow the current submission instructions rather than assuming the status from a prior interface version.
10. Monitor review and release
Watch App Store Connect and the review contact inbox. Respond with precise steps and evidence if App Review asks a question. If rejected, identify the exact guideline and the observed behavior before changing code or metadata. After approval, verify the intended release state and check the live product page, downloads, server health, purchases, crashes, ratings, and support volume.
Copyable final check
- Agreements, identifiers, roles, and capabilities are valid.
- The processed build matches the tested release archive.
- Metadata, screenshots, URLs, and localizations are complete.
- Privacy, age rating, encryption, and content rights are accurate.
- Pricing, availability, purchases, and release method are confirmed.
- Review credentials and numbered instructions work from a clean device.
- The app was added to the submission and actually submitted for review.
- Monitoring and post-release ownership are assigned.



