Why does the App Store reject apps? The 10 most common reasons
The App Store rejects an app when it breaks a rule in Apple’s App Review Guidelines. By Apple’s own account, more than 40% of unresolved issues, on average, relate to a single guideline — 2.1 App Completeness, which covers crashes, placeholder content and incomplete information. Most of the remaining reasons come from store metadata, privacy and purchasing rules.
We covered the whole release process — developer account, TestFlight, review — in our guide to the App Store review process. This piece answers a narrower question: when a rejection arrives, what does each guideline number mean, and how do you avoid it next time? We checked every guideline number against the version Apple published in October 2026.
How do you read a rejection message?
Every rejection starts with a guideline number, so find that first. The message in App Store Connect carries a line such as “Guideline 2.1 - Performance - App Completeness”, followed by what the reviewer saw and, often, a screenshot.
When a rejection comes in, we suggest looking at three things:
- The guideline number. It tells you which family of rules is involved: 2.x is performance and metadata, 3.x is business, 4.x is design, 5.x is privacy and legal.
- The reviewer’s device and steps. A rejection is often a problem seen on one iPad model or in one particular flow. Reproduce it on the same kind of device before changing anything.
- Fix or explain? Sometimes the app is fine and the reviewer simply couldn’t find a feature. Then the review notes need fixing, not the code.
According to Apple’s App Review page, at least half of submissions are typically reviewed in under 24 hours and 90% in under 48. A rejection that has been read properly usually closes within a few days.
The 10 most common rejection reasons, with guideline numbers
The list below draws on the topics Apple lists under “Avoiding common issues” and the matching guidelines. The order reflects Apple’s figure and our own view.
1. An app that crashes or feels unfinished (2.1)
Guideline 2.1(a) asks for a final version, with placeholder text and temporary content scrubbed before submission. A “coming soon” button, an empty screen or a crash on the reviewer’s device all fall here — and this is where Apple says the largest share of problems lies.
2. No demo account (2.1)
If the app needs a login, the reviewer needs a working demo account and a live back end. Without one, review stops. An app with no account never meets this rule at all; we explain why Tako works that way in a separate studio note.
3. In-app purchases the reviewer can’t find (2.1(b))
In-app purchases must be complete, visible and working during review. If the purchase screen sits behind a setting or only appears under certain conditions, say how to reach it in the review notes.
4. Vague review notes (2.3.1(a))
New features must be described “with specificity” in the Notes for Review; Apple states plainly that generic descriptions will be rejected. “Bug fixes and improvements” can cause trouble on a major update.
5. Screenshots that don’t show the app (2.3.3)
Screenshots should show the app in use — not merely title art, a login page or a splash screen. Framing them and adding captions is fine; the screens shown must actually exist in the app.
6. Stuffed names and keywords (2.3.7)
App names are limited to 30 characters and can’t be padded with trademarks, popular app names or pricing. Guideline 2.3.10 also bars the names and imagery of other mobile platforms in your metadata, so “also on Android” will trip it.
7. A missing or inaccurate privacy policy (5.1.1(i))
The privacy policy must be linked both in App Store Connect and inside the app. It should explain what is collected, whether it is shared with third parties, how long it is kept and how it can be deleted. Add an advertising or analytics library without updating the policy, and the declaration and the app drift apart.
8. Unexplained permission requests (5.1.1(ii) and (iv))
When asking for the camera, location or contacts, the purpose string must state clearly what the data is for, and users who decline should be offered an alternative. If you track users across apps, guideline 5.1.2 requires the App Tracking Transparency prompt.
9. Accounts that can be created but not deleted (5.1.1(v))
If the app lets people create an account, it must let them delete it from within the app. The same guideline asks that, where an app has no significant account-based features, people can use it without logging in. This one is often missed, because account deletion usually means separate work on the server.
10. Minimum functionality and look-alike apps (4.2, 4.3)
Guideline 4.2.2 says apps shouldn’t primarily be marketing materials, web clippings or collections of links. Guideline 4.3 treats submitting the same app under several bundle IDs as spam. Template-built apps that barely differ from one another get caught here.
How do you prevent each one?
Every rejection reason has a counter-measure, and most can be caught with a ten-minute check before submission. We suggest using this table as a checklist before you submit.
| Guideline | Rejection reason | Before you submit |
|---|---|---|
| 2.1(a) | Crashes, placeholder content | Run the app end to end on a real device from a clean install |
| 2.1 | No demo account | Username, password and brief instructions in the review notes |
| 2.1(b) | Purchase not found | Describe the path to the purchase screen in the notes |
| 2.3.1(a) | Generic review notes | Name every new feature individually |
| 2.3.3 | Screenshots not showing the app | Capture screenshots from the current build |
| 2.3.7, 2.3.10 | Stuffed name and keywords | Keep the name within 30 characters; no other platform names |
| 5.1.1(i) | Missing privacy policy | Update the policy with every new library |
| 5.1.1(ii) | Unexplained permission | A clear purpose string for each permission |
| 5.1.1(v) | Account can’t be deleted | Build deletion into the first release — or drop the account |
| 4.2, 4.3 | Minimum functionality, copycat | Be able to state the app’s mobile-specific value in one sentence |
If you sell subscriptions or digital content, guidelines 3.1.1 and 3.1.2 also apply — purchases must be restorable, and a subscription must say clearly what the subscriber gets. We cover both in in-app purchases and subscriptions.
An extra condition for health and finance apps
Guideline 5.1.1(ix) asks that apps offering services in highly regulated fields — banking and finance, healthcare, gambling and similar — be submitted by the legal entity that provides the service, not by an individual developer. Apple lists this as “submitted by incorrect entity”.
So if an app is being built for a clinic or a financial firm, we recommend settling at the very start that the developer account is opened in the organisation’s name. Opening the account and verifying the organisation take time, so running that step alongside design protects the schedule. How this affects the plan and budget is covered in what determines the cost of a mobile app.
What should you do after a rejection?
A rejection isn’t final; you can fix and resubmit, or appeal. This is the order we recommend:
- Read the rejection message and screenshot together with the guideline number.
- Reproduce the problem on the kind of device the reviewer used.
- If the problem is real, fix it and say in the new build’s review notes what changed.
- If it’s a misunderstanding, send App Review a short, concrete explanation through App Store Connect.
- If you still disagree, appeal to the App Review Board. Apple asks for one appeal per rejected submission, with specific reasons why the app complies.
Developers whose app is already live have one more route. Apple doesn’t hold up bug-fix submissions over guideline violations unless there are legal or safety issues; you tell App Review you’ll address the issue in your next submission.
What should you check before submitting?
Our view is that, because most rejections come down to preparation, checking should start at the design stage rather than when the code is done. Will there be an account? Which permissions will be requested? Where will purchases sit? The answers to those three questions decide half the rejections that might come later.
Answering them early simplified our submissions for Tako and Mümin 360. Because Tako has no account, the demo-account and account-deletion rules never came up. On updates, too, we recommend writing the review notes separately from the release notes, feature by feature. The full pre-submission checklist is in our guide to the review process.
Frequently asked questions
What is the most common reason for App Store rejection?
According to Apple, more than 40% of unresolved issues, on average, relate to guideline 2.1, App Completeness. That covers crashes, placeholder content and incomplete information. A clean install tested end to end on a real device catches most of them.
Does a rejection mean the app will never be accepted?
No. You can fix the issue in the rejection message and resubmit the same app. If you disagree, you can first explain to App Review and then appeal to the App Review Board. Repeated rejections for the same guideline can, however, lengthen later reviews.
Is an app without an account easier to get approved?
There’s no guarantee of approval, but some rejection reasons simply never arise. Providing a demo account and in-app account deletion only apply to apps that create accounts. Guideline 5.1.1(v) also asks for login-free use where there are no significant account-based features.
Can I use design and text in my screenshots?
Yes. Guideline 2.3.3 asks that screenshots show the app in use; frames, backgrounds and short captions are fine. The screens shown must exist in the current version of the app.
Can updates be rejected too?
Yes — every new version goes through review. That’s why we recommend repeating the first-submission checks on every update. If the app is live and the issue isn’t legal or safety-related, Apple also offers a route for bug fixes not to be held up.
If you’re looking for a team that builds the store rules in from the start, see how we work on our mobile app development page or get in touch. If the platform choice is still open, iOS or Android is a good place to start.
