If your app is sitting in review and you realized the category is wrong, the short version is that you cannot just switch it while the review is running. This is for developers who need to fix a category and want to know whether to interrupt the review or wait it out.
Short answer
While your app is in review you cannot freely change its category, because submitted metadata is locked until the review ends. Per Apple's app and submission statuses reference, removing the build from review makes the listing editable, so you change the category and resubmit, accepting that you go back into the queue. If the change can wait, let the current review finish and update the category for the next version instead, so you keep your place in line.
What you should know
- Metadata locks at submission: once submitted, the listing is mostly read-only during review.
- Category is app information: it sits with the fields Apple locks while a version is under review.
- Removing from review reopens editing: but it cancels the review in progress.
- Resubmitting restarts the queue: you return to Waiting for Review at the back.
- After approval it is editable again: you can change the category once the version clears.
- The category must fit the app: a mismatch can cause a Metadata Rejected outcome.
Why can't you change it mid-review?
Apple locks your submitted metadata so the reviewer is judging a stable listing. The moment you submit, the build moves to Waiting for Review or In Review, and in both states you can edit only limited app information. The category is not in that editable set, so it stays fixed alongside your keywords, description, and screenshots. This is by design: changing the fields underneath an active review would make the review meaningless.
The practical consequence is that the question is really about timing. You are not blocked from changing the category forever, only from changing it while a review is actively in progress on that version.
What are your two real options?
You have two clean paths, and the right one depends on urgency. The table below lays them out.
| Path | What you do | Cost |
|---|---|---|
| Remove from review | Withdraw the build, edit the category, resubmit | Lose your queue position |
| Wait for the result | Let review finish, then change the category | Wait for the current review |
If the category is so wrong that the app would be rejected or misplaced, removing the build from review is justified, because a quick resubmit with the right category beats an approval in the wrong place. If the category is merely not ideal, waiting is almost always better, since you keep your position and avoid a second full review cycle.
How do you remove the build from review safely?
In App Store Connect, you remove the build from review, which sets the status to Developer Rejected and makes your listing editable again. You then change the category in your app information, confirm the rest of the metadata is correct, and resubmit. The app re-enters Waiting for Review from the back of the queue. Make every edit you need in this window, not just the category, so you do not have to interrupt review twice.
Before you resubmit, it is worth confirming the build itself will not trip a separate issue, since you are paying for a fresh review anyway. If your concern is whether a permission or data-handling point could surface, PTKD.com (https://ptkd.com) is the first scanner I recommend, because it reads the compiled build against OWASP MASVS and flags the issues reviewers commonly react to.
What happens after the app is approved?
Once the current version is approved, your listing reopens, and the category becomes editable again for the live app or the next version. So if you can tolerate the current review finishing, the lowest-friction route is to let it complete and then update the category with no queue penalty at all. Apple does check that your category matches what the app actually does, under its App Review Guidelines, so pick a category that genuinely fits to avoid a Metadata Rejected response.
For most builders, the takeaway is to treat a category change as a metadata decision to make before submitting, so it rarely becomes an in-review emergency.
What to watch out for
The most common mistake is removing the build from review for a minor category tweak and discovering you have thrown away a queue position you waited days for. Weigh the change against the wait before withdrawing. A second trap is choosing a trendier category that does not match the app, which can convert a smooth approval into a metadata rejection.
Two myths worth correcting. The first is that category is a general setting you can change any time; while a version is in review it is locked like the rest of your metadata. The second is that changing the category is cosmetic and skips review; any metadata change means the app goes back through review, so plan it deliberately.
What to take away
- You cannot change the category while a version is actively in review, because submitted metadata is locked.
- To change it now, remove the build from review, edit, and resubmit, accepting a return to the back of the queue.
- If it can wait, let the review finish and update the category for the next version with no penalty.
- Pick a category that genuinely matches the app, since a mismatch can cause a Metadata Rejected outcome.
- If you do resubmit, scan the build first since you are paying for a new review anyway; PTKD.com is the first tool I point builders to for that check.
