Most App Store rejections come from a short list of causes: a build that is not finished or stable (Guideline 2.1), listing details that do not match the app (2.3), too little functionality or a copycat feel (4.2 and 4.3), weak privacy handling (5.1) and unclear payments (3.1). Nearly all of them can be caught before you press submit. This guide explains each reason in plain terms, what Apple's reviewers look for, and what to do if a rejection lands anyway.
TL;DR
- Apple reviewed 7.77 million submissions in 2024 and rejected 1.93 million, so a rejection is common, not a sign of a bad app.
- Guideline 2.1 (App Completeness) is the biggest single cause: crashes, placeholder content, broken links and missing demo logins.
- Metadata, minimum functionality, spam or duplicate apps, privacy and payments make up most of the rest.
- Reply in App Store Connect first. Appeal to the App Review Board only once, and only if you believe the app complies.
- For UK launches, line up your privacy notice and subscription wording with UK GDPR and consumer law before review.
Table of Contents
- How much rejection really happens
- The most common rejection reasons, explained
- Rejection reasons at a glance
- A pre-submission checklist that prevents most rejections
- What to do when your app is rejected
- Extra checks for a UK launch
- Our view: rejections are usually a planning problem
- Get a second pair of eyes before you submit
- FAQ
- Sources
How much rejection really happens
Apple's 2024 App Store Transparency Report, as reported by MacRumors, says Apple reviewed 7.77 million submissions and rejected 1.93 million. The leading rejection categories were performance, legal, design, business and safety.
That is roughly one submission in four. If you have just had a rejection, you are in very large company. The useful question is not whether it will happen, but whether the reason is on the list below, because then you can prevent it.
Apple's own App Review guidance is blunt about where the problems sit: more than 40% of unresolved issues relate to Guideline 2.1, App Completeness. If you only have time to fix one area before submitting, fix that one.
The most common rejection reasons, explained
The rules live in Apple's App Review Guidelines. The numbers below match that document, so you can quote them when you reply to a reviewer.
2.1 App Completeness: the build is not ready
Apple expects a final, working version with complete metadata and working URLs. According to the guidelines, it may reject incomplete bundles, crashes, obvious technical problems, placeholder content, or apps where a login service is unavailable.
In practice, this rejection usually comes from small oversights:
- A support or privacy policy link that returns an error.
- "Lorem ipsum" text, empty screens or test images left in the build.
- A demo account that has expired, or one that needs a one-time code the reviewer cannot receive.
- A backend or staging server switched off over the weekend while the reviewer is testing.
- A feature behind a login that the reviewer cannot reach because no credentials were supplied.
The fix is dull and reliable: test the exact build you are submitting, on real devices, from a clean install, and complete every field in the review information.
2.3 Accurate metadata: the listing says something the app does not
Screenshots, descriptions and previews must reflect the real app. A screenshot showing a feature that is still in development, a description that promises something the app does not do, or an age rating that does not fit the content can all trigger a rejection under 2.3.
A good rule: every claim in your listing should be demonstrable in the first few minutes by someone who has never seen the app. If you are rewriting your listing anyway, our guide to app store listing optimisation shows how to stay persuasive without overpromising.
4.2 Minimum functionality: not enough app
Apple wants apps that offer lasting value on iOS, not a repackaged website. The review guidance lists web clippings, substandard interfaces and insufficient lasting value among common problems. This one hits businesses that wrap a mobile site in a thin shell, or that launch a brochure-style app with one screen and a contact form.
The remedy is to give the app something a website does not: native navigation, offline behaviour, notifications that help the user, camera or device features where they make sense, or a account area that people actually use. Good iOS design helps here, and our iOS app design guide covers what a native feel involves.
4.3 Spam and copycats
Apple also flags repeated similar apps, copycats and misleading claims. The risk is highest for agencies or businesses that publish several near-identical apps for different locations, clients or products from a single template. If each app is a variation of the same binary with a new name, expect questions.
Where you genuinely need many similar experiences, consider one app with configuration inside it, rather than many near-duplicates.
5.1 Privacy: data use is not transparent
The guidelines expect transparent data practices: a privacy policy that is accessible, clear explanations of what you collect and why, and permission requests with honest purpose strings. Typical triggers are asking for location, camera or contacts without a clear reason, collecting more than the feature needs, and a privacy policy that does not match what the app does.
Ask for each permission at the moment the user needs the feature, and write the purpose text in plain language. "We use your location to show your nearest store" will pass where "Needed for app functionality" often will not.
3.1 Business and payments: unclear monetisation
In-app purchases must be complete, visible, current and functional, and the metadata should disclose paid items or subscriptions. If your business model is unusual, such as a B2B app where customers pay outside the app, a membership, or content bought elsewhere, explain it in the listing and in the Review Notes. A reviewer who has to guess will usually reject.
Payment rules differ by app type and change over time, so check the current text of Guideline 3.1 before you design a purchase flow rather than relying on what worked on a previous app.
Regulated apps: proof of who you are
Apple says apps in regulated or licensed areas, including banking, financial services, cryptocurrency, healthcare, gambling, lotteries and air travel, may need to be submitted by the responsible legal entity, with supporting authorisation or partnership documents. If your app is in one of these fields, gather the paperwork early. Our note on Apple's crypto rules is a good example of how specific these requirements become, and our health tech work shows how we plan for them.
Rejection reasons at a glance
| Guideline | What Apple flags | Typical cause | Quick fix |
|---|---|---|---|
| 2.1 App Completeness | Crashes, placeholders, broken links, no demo access | Unfinished build, expired demo account | Test the release build on devices; supply working credentials |
| 2.3 Accurate Metadata | Listing does not match the app | Old screenshots, overclaiming | Rebuild screenshots from the submitted build |
| 4.2 Minimum Functionality | Thin app, web wrapper | Website repackaged as an app | Add native features and genuine value |
| 4.3 Spam | Near-identical apps, copycats | Template apps published repeatedly | Consolidate into one app |
| 5.1 Privacy | Unclear data use, weak policy | Over-collection, vague permission text | Minimise data; write clear purpose strings |
| 3.1 Business | Unclear or non-compliant payments | Hidden subscription terms | Disclose pricing; explain the model in Review Notes |
A pre-submission checklist that prevents most rejections
Apple's guidance on preparing for review points to a consistent set of habits. Turn them into a gate your team must pass before every submission:
- Test on real devices. Run the release build, not a debug build, on at least one older and one current iPhone, from a clean install.
- Remove placeholders. Search the project for test text, dummy images and "coming soon" screens.
- Check every link. Privacy policy, terms, support and marketing URLs must all load.
- Complete the review information. Fill in contact details so a reviewer can reach a real person, and keep them up to date.
- Provide valid demo credentials. The account must be active, have realistic data and not depend on a code sent to your phone.
- Explain special configurations. If a feature needs hardware, a location or a particular setup, say so in the notes.
- Keep backend services running. Do not take staging or production offline during review.
- Attach required documents. Licences, authorisations or partnership letters for regulated categories.
This list follows Apple's own review guidance, and the UK version of the guidelines makes the same points about crash testing, complete metadata, current contact details and full access for App Review.
If you do not yet have a disciplined beta process, set one up. Our article on app beta testing with TestFlight shows how to avoid delays, and the app launch checklist puts review into the wider launch plan.
What to do when your app is rejected
Stay calm and read the message properly. The rejection names the guideline and usually describes the issue and sometimes includes screenshots. Most rejections are fixed in a single round.
- Identify the guideline. Note the number and the exact behaviour described.
- Reproduce it. Follow the reviewer's steps on a clean device. If you cannot reproduce it, say so politely and give your own steps.
- Reply in App Store Connect. Apple's UK guidance says you can communicate with App Review there after a rejection. Ask for clarification if the reason is unclear, or explain what you have changed.
- Fix and resubmit. Address the cause, update the Review Notes and submit a new build if code changed.
- Appeal only if you have a case. Apple's appeal guidance says to appeal if clarification has not resolved things and you believe the app complies. Submit one appeal that answers each cited violation point by point. Do not appeal to ask for a status update, or after you have already fixed the issues and resubmitted.
Expedited review exists, but the UK guidelines say it is for genuinely critical timing issues. A marketing date is rarely one, so build slack into your schedule instead.
Extra checks for a UK launch
Apple's rules apply worldwide, but a UK organisation should also think about domestic law, because reviewers look at whether your privacy and payment presentation is accurate.
- Privacy. Align the app's privacy information with UK GDPR and the Data Protection Act 2018: an accurate privacy notice, clear and lawful processing information, consent that users can withdraw, explanations of retention and deletion, and permission requests with a clear purpose.
- Pricing and subscriptions. Be transparent about prices, renewals and cancellation, and make sure any digital content claims are accurate. Apple's UK guidelines still require your metadata and payment presentation to be accurate.
- Sensitive sectors. Health, finance and workforce apps carry extra expectations. If you operate in these areas, see how we approach workforce apps and the points in our piece on launching a secure mobile app.
Get your legal or data protection lead to read the privacy notice and permission wording before submission. It takes an hour and removes a whole class of rejection.
Our view: rejections are usually a planning problem
We have worked on more than 300 projects, and the pattern is consistent: apps rarely fail review because the idea is wrong. They fail because review was treated as the last step rather than a requirement from the start.
Three habits make the difference. First, write the requirements with review in mind: what data you collect, how users pay, and what the reviewer will need in order to log in. Our guide to gathering app requirements is where we begin. Second, prototype early, so thin or web-like experiences show up before a line of production code is written; see how we turn early ideas into testable experiences. Third, keep releases small and frequent, so a fix after a rejection is a routine update rather than a crisis. Our note on continuous deployment explains how that works.
And we recommend the platform that fits the project, not the one that is easiest for us. That honesty up front saves a lot of rework later.
— Paul
Get a second pair of eyes before you submit
If you have an app in trouble, or one about to go to review, our Mobile App Clinics give you an expert assessment of what is working and what needs attention. If you are planning something new, our Discover, Design, Develop and Deploy process builds review-readiness in from the first workshop.
To talk about a project, visit Pocket App and get in touch.
FAQ
What is the number one reason apps are rejected by Apple?
Guideline 2.1, App Completeness. Apple's guidance says more than 40% of unresolved issues relate to it. It covers crashes, placeholder content, broken links and demo accounts that do not work, so a thorough test of the release build catches most of it.
Can I resubmit straight away after a rejection?
Yes. Once you have fixed the issue, you can submit again, adding notes that explain the change. Do not also lodge an appeal for the same issue: Apple's guidance says not to appeal after you have addressed the problem and resubmitted.
When should I appeal instead of replying?
Reply in App Store Connect first. If that does not settle the matter and you believe your app follows the guidelines, submit a single appeal to the App Review Board that answers each cited violation point by point.
Does a rejection hurt my chances next time?
Apple does not say that a rejection counts against you, and with 1.93 million rejections in 2024 they are routine. What matters is that you fix the cause and give the reviewer what they need, including working login details and clear notes.
Do UK apps face different rules?
The App Review Guidelines apply globally, and Apple publishes a UK version. In addition, your app should follow UK GDPR, the Data Protection Act 2018 and UK consumer law on pricing, renewals and cancellation.
Sources
- Apple Shares 2024 App Store Data: Rejections, Removals, and More (MacRumors)
- App Review Guidelines (Apple Developer)
- App Review Guidelines, UK (Apple Developer)
- App Review: Distribute (Apple Developer)
- Appeal to the App Review Board (Apple Developer)