Publish an iOS App on the App Store: step-by-step

Apps mobile · By · Published on · Updated on · 8 min read

Person using a laptop with code on the screen, smartphone connected and a cup of coffee nearby
Development scene: code on the laptop, smartphone connected, and coffee. Photo: Christina Morillo / Pexels

This end-to-end guide shows how to publish an iOS app on the App Store. You’ll find the requirements, project setup, creating the app record in App Store Connect, building with Xcode or CI, uploading with Transporter or Fastlane, TestFlight testing, and submitting for review. Follow these steps to avoid common rejections.

Prerequisites and required accounts

Before publishing, make sure you meet the essential requirements. You must have an active Apple Developer Program membership and a Mac with Xcode installed. Also define the app identifier and prepare required assets such as icons, screenshots, and a privacy policy.

Use this checklist to get started without blockers.

  • Active Apple Developer Program membership.
  • Mac with an Xcode version compatible with the target SDK.
  • Access to App Store Connect with app management permissions.
  • Reserved, unique Bundle ID.
  • iOS distribution certificates and provisioning profiles.
  • App version and build number set.
  • Privacy policy URL and support website.
  • Icons and screenshots in required sizes.
  • Test credentials and dummy data if the app requires login.
  • API key for App Store Connect (optional, for automation).
Requirement Purpose
Apple Developer Program Code signing and App Store publishing.
App Store Connect App registration, metadata and submissions.
Certificates and profiles Sign distribution builds with a valid identity.
Icons and screenshots Compose the app’s App Store listing.
Privacy policy Transparency about data collection and use.

Configure the iOS project (Bundle ID, version and signing)

In Xcode, open the project and update identifiers and versions. The Bundle Identifier must match the one registered in App Store Connect. In Signing & Capabilities, enable automatic signing or upload certificates and provisioning profiles manually.

Review Info.plist. For APIs that access the camera, photos, microphone, location or Bluetooth, include usage messages. Without them, the app will be rejected.

  • Update CFBundleShortVersionString (version) and CFBundleVersion (build).
  • Confirm the Product Bundle Identifier is unique and stable.
  • Add required entitlements and capabilities (e.g., Push Notifications).
<!-- Exemplo de chaves no Info.plist para permissões -->
<key>NSCameraUsageDescription</key>
<string>Precisamos da câmera para ler QR Codes.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>Usamos sua galeria para selecionar imagens do perfil.</string>
<key>NSLocationWhenInUseUsageDescription</key>
<string>Usamos sua localização para mostrar lojas próximas.</string>

Create the app in App Store Connect and required metadata

In App Store Connect, create the app record with name, platform, Bundle ID and SKU. Then fill in the information required for the app listing.

Include description, keywords, category, age rating, privacy policy and data collection details. If you use ads, declare IDFA usage. Prepare review notes and test credentials if login is required.

If your release process frequently fails, a deploy process audit and remediation plan can help reduce risk.

  • App name and primary language defined.
  • Bundle ID correctly linked to the record.
  • Clear, concise app description.
  • Keywords aligned with search intent.
  • Primary and secondary categories selected.
  • Accurate age rating applied.
  • Valid support URL and privacy policy.
  • Data collection and tracking details disclosed.

Generate the build (Archive) with Xcode or a CI pipeline

With the project configured, create an Archive. In Xcode: Product > Archive and then export for the App Store. In automation, use xcodebuild on a macOS runner. This requires valid certificates and distribution provisioning profiles.

CI/CD pipelines help standardize builds and reduce errors. See a CI/CD pipeline guide and adapt it for iOS jobs on macOS runners.

  • Use an increasing build number for every upload.
  • Export the .ipa with ExportOptions for distribution.
  • Manage signing automatically or with tools like Fastlane Match.
# Archive do esquema de Release
xcodebuild -scheme "SeuEsquema" \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -archivePath build/SeuApp.xcarchive \
  clean archive

# Exporta o .ipa para distribuição (usa ExportOptions.plist)
xcodebuild -exportArchive \
  -archivePath build/SeuApp.xcarchive \
  -exportPath build/export \
  -exportOptionsPlist ExportOptions.plist

# Exemplo mínimo de ExportOptions.plist (coloque em arquivo separado)
# <?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>method</key><string>app-store</string>
#   <key>signingStyle</key><string>automatic</string>
#   <key>uploadSymbols</key><true/>
# </dict>
# </plist>

Upload the .ipa with Transporter or Fastlane

Upload the generated .ipa. Graphical option: Transporter (macOS app). Automated option: Fastlane, which integrates build and upload. Make sure 2FA is enabled and you have a valid session to avoid CLI failures.

Example lanes for beta (TestFlight) and release (App Store) with Fastlane.

  • Store credentials securely and rotate tokens when needed.
  • Avoid committing certificates and profiles; manage them with access control.
  • Alternatively, upload directly from Xcode using Distribute App.
# Fastfile (exemplo simplificado)
default_platform(:ios)

platform :ios do
  desc "Build + upload para TestFlight"
  lane :beta do
    build_ios_app(
      scheme: "SeuEsquema",
      export_method: "app-store"
    )
    upload_to_testflight
  end

  desc "Upload para App Store (sem mexer em metadata)"
  lane :release do
    upload_to_app_store(
      skip_screenshots: true,
      skip_metadata: true
    )
  end
end

TestFlight: beta testing and approval criteria

After upload, the build goes through processing. When available, enable TestFlight for internal or external testing. External builds go through basic validation before being released to testers.

Collect feedback, bug reports and stability metrics. Define clear exit criteria before moving to release. If your roadmap and scope are still maturing, review mobile apps planning and scope ideas.

  • Test on supported devices and iOS versions.
  • Validate onboarding, login and critical flows, including offline behavior.
  • Provide clear release notes for testers.
  • Track crashes and fix regressions before final submission.

Submit for review: compliance checklist

With the build validated in testing, select the build for the release, fill in the release notes and submit for review. Review time varies depending on the app and the review queue.

Complete this checklist to reduce rejections and rework.

  • Export compliance: declare cryptography usage and details.
  • Content rights: licences for third-party media if used.
  • Accessible, up-to-date privacy policy on your site.
  • Access to paid features: provide a test environment and accounts.
  • Tracking transparency: declare usage when applicable (e.g., IDFA).
  • Purpose strings in Info.plist for sensitive data.
  • Account deletion flow, if the app requires user registration.

How to confirm it worked and publish

Monitor statuses in App Store Connect. After “Waiting For Review” and “In Review,” an approved app moves to “Ready for Sale.” You can release manually or use a phased release.

If a build fails processing or returns an error, adjust signing, versions and metadata and resubmit. These errors are common and have quick fixes.

  • ITMS-90164/90035: signing issues — review certificates and entitlements.
  • Invalid Bundle Identifier: Bundle ID in Xcode differs from App Store Connect.
  • Duplicate CFBundleVersion: increment the build number.
  • Missing Purpose String: add permission messages in Info.plist.

Frequently asked questions

Do I need a paid account to publish on the App Store?

Yes. An active Apple Developer Program membership is required to sign distribution builds and manage apps in App Store Connect. Without it you cannot upload builds or publish.

What’s the difference between version and build number?

The version (e.g., 1.2.0) is visible to users and changes when new features are released. The build number (e.g., 45) is internal and must increase with every upload. You can submit multiple builds for the same version, but each build must have a higher build number.

Can I publish without using a Mac?

iOS app compilation requires macOS and compatible tools. If you don’t have a local Mac, use CI providers with macOS runners to compile and sign the app, then upload via CLI or Transporter.

How long does app review take?

Times vary by app type, complexity and review queue. Approvals can happen the same day or take several days. Rejections extend the timeline. Be ready to respond quickly to review team requests.

Do I need a privacy policy to publish?

If the app collects user data, integrates third-party login, or uses sensitive APIs, you must provide a privacy policy. Even minimal data collection benefits from a public, up-to-date policy to avoid rejections and increase transparency.

What should I do if my app is rejected?

Read the rejection reason, fix the indicated issue and submit a new build or metadata update. Include concise notes explaining the fix. If needed, attach videos or test credentials to demonstrate the corrected behavior.

Want to automate your iOS release pipeline?

If you need help with signing, standardizing builds or integrating Fastlane and CI, let’s discuss your setup and next steps.

Talk about iOS publishing

See also