Re-upload an iOS app to the App Store

If you're new to shipping iOS, read Re-upload an iOS build to TestFlight first — same prerequisites apply (Mac, Xcode, Apple Developer Program, App Store Connect record). The App Store flow assumes your app is already live in the store; this tutorial covers shipping an update.

If this is your very first App Store submission, the flow is similar but adds the initial app metadata creation. Apple's first-submission guide ↗ covers it; come back here for the re-upload pattern.

Same as TestFlight uploads. In Xcode → target → General → Identity:

• Version (CFBundleShortVersionString) — bump it. For a public release this should change (e.g., 1.2.0 → 1.3.0 or 1.2.1).
• Build (CFBundleVersion) — increment by 1.

Apple expects a real Version bump for App Store submissions. "1.2.0 → 1.2.0" gets rejected; "1.2.0 → 1.2.1" or "1.2.0 → 1.3.0" works.

CFBundleShortVersionString docs ↗ · Semantic versioning primer ↗.

Identical to TestFlight:

• Set destination to Any iOS Device (arm64).
• Menu Product → Archive.
• In the Organizer window: Validate App first (catches signing/entitlement bugs).
• Then Distribute App → App Store Connect → Upload.

Alternative uploaders: Transporter app ↗ (drag IPA, click Deliver) or xcrun altool with an App Store Connect API key.

See the full archive/upload walkthrough in Re-upload an iOS build to TestFlight.

Apple processes the build in 5–30 minutes. Watch in App Store Connect ↗ → your app → TestFlight tab. When you see the new build there with status Ready to Submit, you can attach it to an App Store release.

In App Store Connect → your app → App Store tab (left sidebar).

Click the + Version button next to the version dropdown (top left). Enter your new Version (e.g., 1.2.1) — must match what's in your build's CFBundleShortVersionString.

This creates a new "version page" that you'll fill out and submit.

Scroll down to Build section on the new version page. Click + (Add Build). Pick the build you just uploaded.

If your build doesn't appear, processing isn't finished yet — wait a few more minutes and refresh.

In the What's New in This Version field, write user-facing release notes. These show in the App Store on the version's update screen.

Good notes are:

• Specific — "Fixed the crash when opening Settings while offline" beats "Bug fixes."
• Short — 3–5 bullet points max.
• User-focused — describe outcomes, not implementation. "Faster project loading" beats "Refactored project parser."

Localize for every language you've added if you have translations. App Store localization docs ↗.

You don't have to update screenshots/description/keywords on every release — only when something user-facing changed enough to warrant new images.

If you do need new screenshots:

• Required sizes — at least one set of iPhone screenshots (6.7" or 6.9" for newest models). iPad if you ship to iPad. Current screenshot specs ↗.
• Generate them — Xcode → Window → Devices and Simulators → screenshot from a Simulator; or use fastlane snapshot ↗ for automation.
• Frame them (optional) — tools like fastlane frameit ↗ or Shotbot ↗ add device frames + text overlays.

You can also update: Description, Keywords (100 chars total, comma-separated), Support URL, Marketing URL, Promotional Text (170 chars, can be edited any time without resubmitting). Optional but worth keeping fresh.

Scroll to Version Release section. Three options:

• Manually release this version — after approval, your update sits at "Pending Developer Release" until you click a button. Right for coordinated launches.
• Automatically release this version — goes live the moment Apple approves it. Right for routine updates.
• Automatically release after App Review using phased release for automatic updates — releases to users in waves over 7 days (1% day 1, then 2%, 5%, 10%, 20%, 50%, 100%). Right for risky updates; lets you catch regressions before everyone gets them.

For most updates, phased release is the safe default. You can pause it at any percentage if something breaks. Phased release docs ↗.

App Store Connect will surface a checklist of things that may need updating. The big ones:

• Privacy policy URL — required; must be live and reachable.
• App Privacy — data collection disclosures. Update if you added new tracking/data collection. App Privacy docs ↗.
• Age Rating — re-answer if content changed.
• Export Compliance — usually inherits from your build. Encryption export docs ↗.
• Content Rights — confirm you have rights to all content you ship.

When every required field has a green check, the Add for Review button (top right) becomes active. Click it. The version moves to Waiting for Review.

Then click Submit to App Review. The version status flows: Waiting for Review → In Review → Pending Developer Release (if manual) or Ready for Sale (if auto).

App Store Review timing:

• ~24 hours typical (per Apple's own published metrics ↗)
• 1–3 days realistic range for normal updates
• Up to 7 days for first submissions, big changes, or edge-case content

If rejected, you get a message in the Resolution Center (App Store Connect → your app → top nav) explaining why. Reply with the fix or an explanation; resubmit. Most rejections are fixable in one revision cycle.

• Guideline 4.0 – Design / 4.3 – Design Spam — looks too similar to an existing app or generic. Rare; usually for cookie-cutter apps.
• Guideline 2.1 – Performance: App Completeness — crashes during review, broken sign-in, placeholder content. The reviewer couldn't use the app. Most common rejection.
• Guideline 5.1.1 – Privacy — collecting data not declared in App Privacy; missing privacy policy.
• Guideline 3.1.1 – In-App Purchase — using something other than IAP for digital goods, or trying to direct users to external payment.
• Metadata Rejection — screenshots show a different app than is being submitted; description has competitor names; promotional text claims unsupported features.

Full ruleset: App Store Review Guidelines ↗.

Watch sales / downloads / crash rate after release:

• App Store Connect → Analytics for downloads + revenue.
• Xcode Organizer → Crashes tab for crash reports, grouped by stack trace.
• Xcode Organizer → Metrics for launch time, battery, scrolling performance.

If you chose phased release and Crashes shows a regression in the new version, you can halt the phased release in App Store Connect, or submit a hotfix.