The update flow, step by step
- Open your app in App Store Connect and click the + next to iOS App to create a new version (e.g. going from 1.0 to 1.1).
- Update your version number in Xcode to match, then archive and upload the new build via Xcode Organizer or Transporter — same process as your original submission.
- Update whatever metadata changed — description, screenshots, keywords, what's new text. You can change all of these on every version; nothing is locked after your first release.
- Fill in "What's New in This Version." This is the one field unique to updates — a short changelog users see before updating. Keep it specific; "bug fixes and improvements" on every release is a wasted opportunity to tell users (and Apple's reviewers) what actually changed.
- Select your uploaded build for this version and submit for review, exactly like a first submission.
Does every update get re-reviewed?
Yes — any version with a new binary goes through full App Review again, the same guidelines and the same queue as your original submission. There's no "trusted developer, skip review" fast lane for updates in general. What varies is how quickly:
- Updates to already-approved apps often review faster than first-time submissions — sometimes within several hours — because the reviewer isn't evaluating the app from scratch. But this isn't guaranteed, and timing varies with volume and category. See our App Store review time guide for current typical ranges.
- A pure metadata-only change (no new binary — editing description, screenshots, or keywords on the current live version without a new build) can, in some cases, go live without a full re-review, depending on what's changed. This is inconsistent enough that you shouldn't rely on it — assume anything you submit could trigger review.
What you can and can't change without a new build
| Change | Needs a new build? |
|---|---|
| Bug fix, new feature, any code change | Yes |
| Screenshots | No — editable on the current version's metadata |
| Description, keywords, subtitle | No — editable on the current version's metadata |
| Promotional text | No — the one field Apple explicitly allows updating without any review at all |
| Price | No — set independently in Pricing and Availability |
| App icon | Yes — the icon is part of the binary, not metadata |
Promotional text is the standout exception — Apple designed it specifically to be updatable anytime without triggering a review, for exactly this kind of "I want to change my messaging without waiting on review" need. Everything else metadata-related still typically goes through a review cycle, even if it's often quick.
Phased release: rolling out gradually
When you submit an update, you can opt into phased release instead of releasing to 100% of users immediately. Phased release rolls the update out gradually over 7 days (roughly 1%, 2%, 5%, 10%, 20%, 50%, 100% on a fixed schedule), automatically for users with automatic updates enabled. Anyone who manually checks the App Store can still get the new version immediately, regardless of the phase.
This is worth using for any update you're not 100% confident about — it limits exposure if something unexpected goes wrong. You can pause a phased release at any point (without pulling the version), giving you a window to catch issues before it reaches everyone.
Manual vs automatic release, again
Just like a first submission, you choose whether the update goes live automatically the moment it's approved, or waits for you to hit release manually. For coordinated launches — a marketing push, a specific date — manual release plus your own trigger is the safer default, same reasoning as covered in the App Store review status guide's breakdown of "Pending Developer Release."
Updating screenshots on an existing listing
Screenshots are one of the easiest things to refresh on an update, and one of the most neglected. If your app's UI has evolved since launch but your screenshots still show the old version, you're both misrepresenting the current app (a metadata-rejection risk under guideline 2.3.3) and missing a chance to show off improvements that might lift conversion.
ezscreenshots makes refreshing a listing fast — drop your current app's captures, keep the same device presets you used before for consistency, update captions to reflect what's new, and export the full set in minutes. No account, no export limit, all in the browser. A quick screenshot refresh alongside a meaningful update is a good habit to build into your release process, not just something to do once at launch.
Shipping an update? Refresh the screenshots too.
If your UI has changed since your last screenshot set, your listing may no longer match your app — a metadata-rejection risk and a missed conversion opportunity. ezscreenshots gets a fresh, correctly-sized set done in minutes. Free, browser-based, no account.
Try ezscreenshots →Summary
- Every update with a new binary goes through full App Review, same as a first submission — no fast lane for existing developers
- Metadata-only changes (screenshots, description, keywords) don't need a new build, but may still trigger a review cycle depending on what changed
- Promotional text is the one field that updates instantly with zero review, by design
- Phased release rolls an update out gradually over 7 days — a good default for anything you're not fully confident about
- Manual vs automatic release — manual gives you control over exactly when an approved update goes live, useful for coordinated launches
- Refresh your screenshots when your UI changes meaningfully — stale screenshots risk a metadata rejection and miss a conversion opportunity