Why Did Apple Reject My App? Common Reasons
The reasons Apple most often rejects apps, why each happens, and how to prevent them before you submit.
Short answer
Most Apple rejections fall into a few buckets: bugs and crashes the reviewer hits, privacy gaps like a missing privacy policy, broken or incomplete submissions such as a demo login that does not work, guideline violations around payments or spam, and apps that are too thin to justify being an app. The exact guideline Apple cites in its message, drawn from the App Store Review Guidelines, tells you which bucket you are in. Almost all of these reasons are preventable before you submit.
Rejections cluster into a few causes
App rejections can feel mysterious, but in practice they are not very varied. The overwhelming majority come from a short list of causes, and once you know the list, both preventing and fixing rejections becomes far more straightforward. Apple always tells you which guideline your app fell short of, so your first move on any rejection is to read that guideline number, because it points directly to the cause. What follows is the list that number will almost always land on.
Understanding these causes is useful before you ever submit, not just after a rejection. Most of them are things you can check and fix in advance, which means the difference between an app that sails through review and one that bounces back repeatedly is often just knowing what reviewers look for. Treating the common reasons as a pre-submission checklist, rather than a post-rejection autopsy, is how experienced teams get apps approved on the first try.
Bugs and crashes
The most common cause is simply that the app does not work reliably. If a reviewer opens your app and hits a crash, a frozen screen, or a feature that does not do what it claims, that is grounds for rejection, because Apple will not put an unreliable app in front of its users. This catches many teams off guard, because the app worked fine on their own devices. Reviewers test on their own hardware, network, and settings, and problems that never appeared in development can surface there.
The fix is thorough testing before submission, especially on real devices rather than only a simulator, and ideally a round of beta testing through TestFlight so other people exercise the app in conditions you did not anticipate. Pay particular attention to the first-run experience, since a crash on launch or during sign-up is both common and fatal to a submission. An app that is genuinely stable clears this hurdle without drama, which is why quality testing is the highest-value insurance against rejection.
Privacy gaps
Privacy is the second big bucket, and Apple takes it seriously. The most frequent version is a missing or inadequate privacy policy, which Apple requires for essentially every app. Close behind is inaccurate or incomplete privacy information: you must declare what data your app collects, and your actual behaviour has to match those declarations. An app that quietly collects more than it admits, or that asks for permissions and data it does not obviously need, invites a rejection.
Avoiding this category is mostly about honesty and completeness. Provide a real privacy policy, fill in your app’s privacy details accurately, and only request the data and permissions your app genuinely needs, with a clear reason the user can understand. If your app uses location, contacts, or the camera, be ready to justify why. Getting privacy right is not just about passing review; it is about respecting users, and the two goals point in the same direction, which is why a privacy-conscious app rarely trips this wire.
Broken or incomplete submissions
A whole set of rejections come not from the app being bad but from the submission being incomplete, so the reviewer simply cannot do their job. The classic example is a login: if your app requires an account and you do not supply working demo credentials, the reviewer cannot get past the front door and will reject the app. Broken links, placeholder text or images left in the app, features that are visibly unfinished, and missing information for the reviewer all fall in this bucket.
These are the most avoidable rejections of all, because they are about presentation rather than substance. Before submitting, put yourself in the reviewer’s position: provide a working demo account, complete every field of the submission, remove any placeholder content, and use the reviewer notes in App Store Connect to explain anything non-obvious, such as how to trigger a particular feature. An app that a reviewer can fully explore, with no dead ends, removes an entire category of easy rejections.
The common reasons at a glance
The table below summarises the main causes, how often they appear, and the direction of the fix.
| Reason | How common | How to prevent it |
|---|---|---|
| Bugs and crashes | Very common | Test on real devices and via TestFlight |
| Missing or wrong privacy details | Common | Add a privacy policy, declare data honestly |
| Broken demo login or links | Common | Give working credentials and complete info |
| Payment or business-model conflict | Sometimes | Follow Apple’s rules for digital purchases |
| Spam or too thin (Guideline 4.3) | Sometimes | Build a genuine, distinct native app |
The top three rows are the everyday rejections, and they are almost entirely within your control. The bottom two are less frequent but more serious, because they touch how your app makes money or whether it is distinct enough to belong on the store, and fixing them can mean real changes rather than a quick edit.
Guideline and design issues
Beyond the everyday causes sit the deeper ones. Payment rules are a frequent source of surprise: for digital goods and services consumed in the app, Apple generally requires its own in-app purchase system rather than an outside payment method, and apps that try to route around this get rejected. Understanding these rules before you design your revenue model saves painful rework later. Then there is spam and duplication under Guideline 4.3, which catches template-generated apps, thin web wrappers, and clones that add nothing new.
The last bucket is design and minimum functionality. Apple expects an app to offer a genuine, reasonably complete experience, not a barely functional shell or something that would be better as a website. An app judged too limited, or one whose design falls well short of the platform’s norms, can be rejected on those grounds. Building natively and following Apple’s expectations for a real app experience keeps you clear of this, and it overlaps heavily with simply making something good. Where the everyday rejections are about execution, these are about the fundamentals of what you are building.
A pre-submission checklist
Run through this before you submit, and you will avoid the great majority of rejections.
| Before you submit, confirm | Why it matters |
|---|---|
| The app is stable on real devices | Crashes are the most common rejection |
| A privacy policy and accurate data details | Privacy gaps are a frequent trigger |
| Working demo credentials and no dead links | The reviewer must be able to test everything |
| Your payment model follows Apple’s rules | Payment conflicts cause hard rejections |
| The app is genuine, native, and complete | Thin or duplicate apps fail Guideline 4.3 |
Working through this list turns most of the guesswork out of submission. It does not guarantee approval, because review involves judgement, but it removes the predictable reasons, which is most of them. An experienced developer runs this kind of check as a matter of habit, which is a large part of why apps built by seasoned teams are rejected less often. Preventing a rejection is always cheaper and faster than resolving one after the fact.
When a rejection is not your fault, and what next
Even with everything above in order, apps sometimes get rejected, and it is worth keeping that in perspective. Review involves human judgement, so a borderline call can go against you, and the guidelines themselves change over time, so something accepted before can be flagged later. Occasionally a rejection is simply a reviewer misunderstanding how your app works. In those cases the answer is not a frantic rebuild but a clear explanation, and sometimes a second look resolves it. A single rejection is not a verdict on your app.
Whatever the reason, the practical next step is the same: read the cited guideline, decide whether to fix or explain, and respond calmly. Our guide on what happens if Apple rejects your app walks through that process, and our piece on how hard it is to get an app approved sets realistic expectations. If you would rather have an experienced team prepare your submission so it clears review the first time, or help you resolve a rejection now, book a call.
FAQ
Why did Apple reject my app?
Almost always for one of a few reasons: a bug or crash the reviewer encountered, a privacy gap such as a missing privacy policy or unexplained data collection, a broken or incomplete submission like a demo login that does not work, a guideline violation around payments or spam, or an app judged too thin to justify being on the store. The guideline number in Apple's rejection message tells you exactly which reason applies to your app.
What is the most common reason for app rejection?
Bugs and crashes are among the most common. If the reviewer hits a crash or a broken feature while testing your app, it gets rejected, because Apple will not publish an app that does not work reliably. Many of these only appear on the reviewer's device or setup, which is why thorough testing on real devices before submission is the single most effective way to reduce rejections. A stable app clears this hurdle easily.
Can a missing privacy policy get my app rejected?
Yes. Apple requires a privacy policy and accurate privacy information for essentially every app, and a missing or incomplete one is a common rejection reason. You also need to declare what data your app collects and use it in ways that match those declarations. Asking for data or permissions your app does not clearly need is another frequent trigger. Getting the privacy details right and honest before submitting avoids this whole category.
Does Apple reject apps for a broken demo login?
Often, yes. If your app has a login and you do not provide working demo credentials, or the ones you give do not work, the reviewer cannot test the app and will reject it. The same goes for broken links, placeholder content, or features that do not function. From Apple's side, an app it cannot fully review is one it cannot approve, so give complete, working access and notes for the reviewer.
Are Apple rejections usually easy to fix?
Most are. The common reasons, crashes, privacy gaps, a broken demo login, incomplete information, are usually straightforward to correct and resubmit. The harder ones involve payment rules or a spam judgment under Guideline 4.3, which can require reworking your business model or making the app genuinely more distinct. Reading the exact guideline Apple cites tells you whether you are facing a quick fix or a deeper change before you start.