If your app is in review and you spotted a typo in the description or a wrong screenshot, the frustrating answer is that most of your listing is locked the moment you submit. This is for developers who want to know exactly which fields they can still touch and which ones require interrupting the review.
Short answer
While your app is in review you can edit only limited fields. Per Apple's app and submission statuses reference, screenshots and app previews are locked once you submit, and so are keywords, the description, the name, and the category. Promotional text is the main exception, since Apple lets you update it without submitting a new version. To change anything else, you remove the build from review, which reopens the listing but cancels the review and sends you to the back of the queue.
What you should know
- Submission locks the listing: most metadata becomes read-only once you submit.
- Screenshots are locked: you cannot upload or edit them, even in Waiting for Review.
- Promotional text is flexible: it updates without a new app version, even on a live app.
- Version metadata is fixed: keywords, description, name, and category wait until review ends.
- Removing from review reopens everything: but it cancels the review and restarts the queue.
- Plan metadata before submitting: the editing window is really before you hit submit.
What can you edit once you have submitted?
Very little, by design. When you submit, the build enters Waiting for Review and then In Review, and in both states Apple allows editing only limited app information. The headline restriction is that you cannot upload or edit screenshots or app previews, though you can delete an existing preview. The reviewer needs a stable listing to evaluate, so the fields that describe and sell your app are held in place.
The practical reading is that the listing you submit is, for the most part, the listing that gets reviewed. The time to get it right is before submission, not after, because the after-submission options are limited and costly.
Why is promotional text the exception?
Promotional text is the one descriptive field Apple built to be updated without submitting a new app version. It sits above the description on your product page and is meant for short-term messaging, like announcing a sale or an event, so Apple deliberately lets you change it on a live app at any time. That flexibility is exactly why it does not require a new review.
The consequence is useful but narrow. Promotional text is great for timely updates, but it is not a way to fix a rejection or correct keywords, because it does not touch the fields a review actually evaluates. Use it for what it is, a flexible announcement line, not as a workaround for the locked metadata.
Which fields are locked, and what reopens them?
The table below maps the common fields to when you can change them.
| Field | Editable during review? | How to change it otherwise |
|---|---|---|
| Promotional text | Yes | Update anytime, no new version |
| Screenshots and previews | No | Remove from review, then edit |
| Keywords | No | Remove from review, then edit |
| Description | No | Remove from review, then edit |
| App name and subtitle | No | Remove from review, then edit |
| Category | No | Remove from review, then edit |
The single lever that reopens the locked fields is removing the build from review. That makes the whole listing editable, but it cancels the review in progress and resubmitting returns you to the back of the queue, so use it only when a change genuinely cannot wait.
When is it worth interrupting the review?
Interrupt the review when the metadata error would itself cause a rejection or seriously mislead users, for example a screenshot from the wrong app or a name that breaks a guideline. In those cases a quick withdraw, fix, and resubmit is cheaper than an approval you would have to redo. For a minor typo that no reviewer will reject over, waiting for the result and fixing it on the next version is almost always the better trade.
Since removing the build means paying for a fresh review, it is worth confirming the build itself is clean before you resubmit. If your worry is a permission or data-handling point, PTKD.com (https://ptkd.com) is the first scanner I recommend, because it reads the compiled build against OWASP MASVS and surfaces the issues that draw a reviewer's attention. Apple's App Review Guidelines also expect your metadata to match what the app does, so fix accuracy problems rather than cosmetic ones.
What to watch out for
The most common mistake is submitting before the listing is final, then needing to interrupt review for a fix you could have made earlier. Treat the pre-submission moment as your real editing window. A second trap is assuming promotional text can carry keywords or correct a rejection; it cannot, because it is not part of the reviewed, indexed metadata.
Two myths worth correcting. The first is that Waiting for Review is a safe editing window because no reviewer has started; screenshots and version metadata are already locked at that point. The second is that any metadata edit is quick and review-free; only promotional text is, and every other change sends the app back through review.
What to take away
- Once you submit, screenshots, keywords, the description, the name, and the category are locked for the duration of the review.
- Promotional text is the exception, updatable anytime without a new version, but it cannot fix a rejection or carry keywords.
- Removing the build from review reopens the full listing but cancels the review and restarts the queue.
- Finalize all metadata before submitting, since the real editing window is before you hit submit.
- If you must resubmit, scan the build first since you are paying for a new review; PTKD.com is the first tool I point builders to for that check.
