A rejection feels like a verdict, but it is a message. It names a guideline, often describes what the reviewer saw, and sometimes names the device they used. Everything you do next depends on reading it properly. Here is an order that has worked for us.
1. Read the guideline number first
Before you open Xcode, find the guideline number and the surface it points at:
- Metadata (name, subtitle, keywords, screenshots, description): fix it in App Store Connect. Apple's help says that "If your app was rejected for a metadata issue, you can resubmit the same build after resolving the issue." Do not touch code.
- The binary (a crash, a frozen button, a missing feature): you need a new build.
- In-app purchases (missing, not reviewable): usually a submission problem, not a code problem.
- No defect at all, only a date: see 5.6 below.
Then read the rest of the message twice. Note the device, the steps, and any screenshot the reviewer attached. Reproduce what they saw, the way they saw it, before you decide what it means.
2. Choose: reply, fix, or appeal
Reply when the reviewer is missing information. Apple's help says you can correspond with App Review and attach files "until you resubmit". Good reasons to reply: a feature is behind a setting they did not find, a login needs a demo account, the app looks like something it is not. Answer the question asked, point to the exact screen, attach a screenshot or a short screen recording.
Fix and resubmit when the message describes something real. This is most rejections. Fix the cause, not the symptom the reviewer happened to hit: if one permission path crashed, test every permission path by hand.
Appeal only in the case Apple describes. Apple's App Review page says that if "you feel we misunderstood your app's concept and functionality, or that you were treated unfairly", you may appeal to the App Review Board, and asks you to:
- give specific reasons why the app complies with the guidelines,
- submit only one appeal per rejected submission,
- answer any request for more information before appealing.
An appeal is not a second try at the same argument in a louder voice. If you have not replied yet, reply first.
If the app is already live and you are shipping a bug fix, Apple's guidelines say bug fixes "will not be delayed over guideline violations except for those related to legal or safety issues". Apple may offer this as a bug fix submission; you accept by replying in App Store Connect and fixing the other issue in your next version.
3. Resubmit the same version
While a version is rejected, you cannot start the next one. Apple's help says the current version must be Ready for Distribution before you can create a new version. So the fix goes into the rejected version:
- Upload a new build with a higher build number, and select it on the same version in App Store Connect.
- Fix any metadata on that same version page.
- If you need a different version number, edit it on the rejected version; in our experience that field stays editable there.
- Resubmit from the App Review section.
If the submission shows Unresolved Issues, Apple's rules are specific: you either edit and resubmit the rejected items, or remove them; you can edit an item once before resubmitting; you can't add new items to that submission; and an item you remove can't be added back to the same submission.
4. Check your in-app purchases came back with you
When an app version is rejected, the purchases submitted with it usually come back marked as rejected too, even when nothing is wrong with them. They are rejected because the version was.
Before you resubmit, open each purchase and subscription and make sure it is in the submission again, alongside the version. The first purchase of each type has to go with an app version, and Apple's help says the version and every purchase you want reviewed together must be in the same draft submission before you submit. If you skip this, a fixed app comes back with a 2.1(b) rejection for missing purchases.
5. What a 5.6 "review suspended" date means
A Guideline 5.6 message can name no defect at all, only a quality standard and a date. In our experience, replies and resubmissions sent before that date are not read. Treat the date as a schedule, not a bug: do not resubmit early, do not guess at patches, and use the time to test the app on a clean device as a stranger would. When the date passes, start with one small, careful resubmission. More in 5.6, review suspended.
What not to do
- Do not resubmit unchanged. Apple's guidelines say that if an app "is repeatedly rejected for the same guideline violation", review "will take longer to complete".
- Do not change code for a metadata finding, or metadata for a code finding. Fix what was named.
- Do not add a disclaimer and hope. One message we received said that "adding a disclaimer to the app description is not sufficient if the rest of the metadata and the app are misleading". If the feature is the problem, the fix is a new build.
- Do not hide the problem. Guideline 2.5.19 forbids hidden or undocumented features. Showing the reviewer something different from what users get is far worse than the original rejection.
- Do not create a new app record to start over. Apple lists "repeated submission of similar apps" under Guideline 4.3; see 4.3, spam.
- Do not argue in the reply. Be specific and short. Apple's code of conduct (5.6) asks for respect in every message you send them.
Guides by guideline
- 2.1, bugs and missing purchases: App Completeness
- 2.3.2: paid features in the description
- 2.3.3: screenshots
- 2.3.7: price words like "Free"
- 2.3.8: store name and home-screen name differ
- 2.4.5, Mac: sandbox saves and update checks
- 2.5.4: background modes
- 4, Mac: no way to reopen the window
- 4.1(c) and 5.2.5: other people's brands in metadata
- 4.3: spam
- 5.6: review suspended
- The VPN question: scan the build, then answer
One-minute check
Before you press Resubmit: the guideline number is written down, the fix touches the surface the message named, every in-app purchase is back in the submission, and your reply says in two or three sentences what changed and where to see it. Then go through the rest of the pre-submit checklist again; a new build resets the build checks. Browser tools for each step are on the toolkit page.
These notes are from Obelisk Club's own submissions. Apple's process and wording change; check the current App Review Guidelines, App Store Connect Help and your own message.