The first App Store rejection is frightening if nobody has told you it is normal. It is normal. Across the apps we have submitted, rejection is a routine step in a fair number of first submissions, and almost never about the code. It is about the paperwork around the code, which is why it catches teams who treated compliance as the last task.
Privacy answers that do not match the app
Both stores ask you to declare what data your app collects. Apple calls it the privacy nutrition label, Google calls it the Data safety form. Reviewers compare your declaration to what the app demonstrably does, and a mismatch is one of the most common reasons a submission comes back.
The usual cause is innocent: an analytics or crash reporting library collects a device identifier, nobody thought of that as "collecting data", and the form says the app collects nothing. The fix is to enumerate every third-party SDK before filling the form, and declare what they collect as well as what you collect. Your dependencies are collecting on your behalf.
Account deletion, in the app
If your app lets people create an account, it must let them delete it from inside the app. Not by emailing support. Not by a link to a web form buried in settings. In the app, and it must actually delete the data rather than deactivating a flag.
This one is expensive to retrofit because deletion is a data modelling problem, not a screen. What happens to a user's reservations when they delete their account? Their reviews? Their subscription? We design the deletion cascade alongside the schema now, because discovering it at submission means rewriting queries under time pressure.
Permission text nobody wrote
Every permission an iOS app requests needs a usage description explaining why. Default text, placeholder text, or text that says "this app needs camera access" without saying what for, gets rejected. The string has to name the feature: what the user gets in exchange for saying yes.
Related and just as common: requesting a permission the app never uses, usually left behind by a library you removed. Audit the permission list against actual features before submitting.
Tracking consent that fires too early
On iOS, if you track users across other companies' apps or websites, you must ask through App Tracking Transparency. Two mistakes recur. Asking on first launch before the user knows what the app is, which tanks the opt-in rate and sometimes draws a rejection for lacking context. And collecting the identifier before the prompt is answered, which is a straightforward violation.
The sign-in trap
If your app offers third-party sign-in such as Google or Facebook, Apple requires you to offer Sign in with Apple too. Teams who add social login late get caught by this, because it is not a setting: it is an authentication flow, with its own token handling and its own edge cases around the private relay email address.
How to make it boring
Prepare the compliance work before the code is finished, not after. Developer accounts take time to approve. Legal pages need to exist at a public URL before you can reference them in the listing. Privacy declarations need the SDK audit done first.
When a rejection does arrive, read the reviewer's note carefully rather than guessing, reply in the Resolution Center if anything is ambiguous, fix it and resubmit. Most turn around in a day or two. Treated as part of the process, it costs a couple of days; treated as an emergency, it costs a launch date. We handle this end to end as part of store launch and compliance, and the goal is never to avoid rejections entirely. It is to make them cheap.