What Happens If Apple Rejects My App?

Short answer

A rejection is not the end, and it does not harm your account. Apple explains why in the Resolution Center in App Store Connect, citing the specific guideline your app did not meet, and your app simply stays private until you fix the issue or explain why it already complies, then resubmit. Most rejections are common and fixable, and a resubmission is usually reviewed within a day or so. Treat it as a normal step in getting to launch.

A rejection is normal, not a verdict

The first thing to understand is that a rejection is a routine part of publishing an app, not a judgement that your app is bad or that you did something wrong. A very large share of apps are rejected at least once before they go live, including apps from experienced teams. App review is a checkpoint, and like any checkpoint it sometimes sends you back to fix something before waving you through. Reacting with panic leads to bad decisions; reacting calmly and reading what Apple actually said leads to a quick resolution.

It also helps to know what a rejection does not do. Your app is not deleted, your account is not penalised, and nothing becomes public. The app sits in a rejected state, visible only to you, until you act. You have as much time as you need to respond, and resubmitting does not cost anything. Once you internalise that a rejection is a pause rather than a failure, the whole situation becomes a straightforward task: find out what Apple wants, and give it to them.

What actually happens when Apple rejects your app

Mechanically, the process is simple. When a reviewer rejects your app, Apple posts a message in the Resolution Center inside App Store Connect. That message names the section of the App Store Review Guidelines your app fell short of, and often includes a short explanation or a screenshot showing the problem. This is the single most important piece of information you have, because the guideline number tells you exactly what to address.

From there, you have a direct line of communication with Apple through the same Resolution Center. You can reply with questions, provide more information, or let them know you have made a fix. Your app stays in its rejected state throughout, and no version of it reaches the public. When you resubmit a corrected build, or when Apple accepts your explanation, the app moves forward again. The whole interaction is a conversation about one or more specific points, which is far less intimidating than the word rejection suggests.

The two paths: fix it or explain it

Every rejection leads to one of two responses, and choosing the right one matters. The first path is to fix the app. If Apple found a genuine problem, a crash, a missing privacy policy, a broken feature, then the answer is to correct it, test the fix, and resubmit. This is the right path for the majority of rejections, because most cite real issues, and fixing them is faster than debating them.

The second path is to explain. Sometimes a reviewer misunderstands how your app works, or flags something that actually does comply. In that case you reply in the Resolution Center, calmly and specifically, explaining why the app meets the guideline and, if helpful, how to reproduce the correct behaviour. If the reason is vague, it is entirely reasonable to ask Apple to point to exactly what triggered the rejection. Choose this path only when you genuinely believe the app complies; arguing about a real problem wastes time you could spend fixing it.

Common rejection reasons and what they take to fix

Rejections vary enormously in how much work they require, from a five-minute listing fix to a serious rethink. Knowing which kind you are facing helps you plan.

Rejection reason	Typical fix	Effort
Crashes or bugs during review	Fix the bug, test, resubmit	Low to medium
Missing privacy policy or data disclosure	Add the policy and complete the details	Low
Guideline 4.3 spam or duplicate	Make the app genuinely distinct	High
Incomplete metadata or broken links	Fix the listing and reviewer notes	Low
Payment or business-model conflict	Rework how the app charges	High

Many rejections sit in the low-effort rows: a missing privacy policy, a demo account the reviewer could not log into, a link that did not work, or a bug that only appeared on the reviewer’s device. These are quick to resolve. The high-effort rows, such as a spam rejection under Guideline 4.3 or a conflict with how you planned to take payment, mean real rework, because Apple is objecting to something fundamental rather than a detail. Reading the cited guideline tells you which situation you are in before you start.

How to respond, step by step

A calm, methodical response resolves most rejections quickly. This checklist keeps you from making the situation worse.

Step	What to do
Read the exact guideline cited	Know precisely what triggered the rejection
Decide: fix or explain	Fix a real issue; reply only if it truly complies
Respond in the Resolution Center	Ask Apple for specifics if the reason is unclear
Test the fix before resubmitting	Avoid a second rejection for the same thing
Resubmit and track the review	It re-enters the queue, usually reviewed quickly

The step people skip is testing the fix before resubmitting, often because they are keen to get the app live. Resubmitting without properly checking the fix risks a second rejection for the same reason, which is slower than taking an extra hour to be sure. Testing a corrected build with real testers through TestFlight before you resubmit is a reliable way to confirm the problem is genuinely gone, especially for crashes and bugs that depend on the device.

Mistakes that cause a second rejection

The most frustrating outcome is a second rejection for a problem you thought you had solved, and a few avoidable mistakes cause most of them. The first is resubmitting too quickly, before the fix has been properly tested, so the same crash or broken link appears again on the reviewer’s device. The second is fixing only part of what Apple raised: a single rejection can cite more than one guideline, and addressing one while ignoring another sends the app straight back. Read the whole message, not just the first line.

A third mistake is quietly changing the app in ways you did not mention, which can raise new questions even as you resolve the original one. When you resubmit, use the reviewer notes to explain clearly what you changed and how to see it working, including a working demo account if the app needs a login. A reviewer who can immediately reproduce your fix approves it faster than one left guessing. Treating the resubmission as a clear, complete answer to everything Apple raised, rather than a hurried retry, is what turns a rejection into an approval on the next pass. It also helps to respond promptly while the context is fresh, since a reviewer picking the app up again moves quickest when your reply directly addresses their note.

When a rejection is harder to resolve

Most rejections are minor, but it would be dishonest to pretend all of them are. Some cut to the core of the app or the business. A repeated Guideline 4.3 rejection means Apple does not consider your app distinct enough, and no amount of explaining changes that; the fix is to make the app genuinely more than a template or wrapper. A rejection over how you take payment can mean reworking your revenue model to fit Apple’s rules. These are real obstacles, and solving them can take significant work rather than a quick edit. In those cases it is worth stepping back to ask whether the app, as designed, can meet Apple’s rules at all, because changing the approach early is cheaper than resubmitting the same idea and being rejected again.

The deeper point is that some rejections are best avoided before submission by building the app correctly in the first place, which is where an experienced team earns its keep. Understanding how hard it is to get an app approved and preparing the submission properly heads off most of the painful cases. If your app has been rejected and you are not sure how to move forward, or you want to make sure a new app clears review cleanly the first time, we can help. Book a call and we will look at what Apple flagged and how to resolve it.