App Store Rejection Reasons First-Time Developers Hit, and How to Avoid Them (2026)
The App Review guidelines that stop most first apps, what Apple’s own numbers say about rejections, and a pre-submission checklist that heads them off.
Key Takeaways
- Completeness is the biggest single cause. Apple says that on average over 40% of unresolved issues relate to guideline 2.1, App Completeness: crashes, broken links, placeholder content and missing demo logins.
- A rejection is usually a delay, not a verdict. Apple’s 2025 transparency report counts 387,087 submissions approved after an initial rejection. Fix the cited issue, reply in App Store Connect and resubmit.
- Websites in an app frame get flagged under 4.2. Apple asks for features, content and UI that “elevate it beyond a repackaged website.” Accounts, saved data and notifications help; a wrapped brochure site doesn’t.
- Two privacy items are non-negotiable. Every app needs a working privacy policy link in App Store Connect and inside the app, and any app that lets people create an account must let them delete it from within the app.
- Review notes are part of the submission. A demo account, a two-sentence explanation of the app and a reason for each permission prevent most of the back-and-forth that turns a one-day review into two weeks.
Quick-Start Prioritization Framework
| Rejection reason | Guideline | How likely for a first app | Fix before you submit |
|---|---|---|---|
| Crashes, broken links, placeholder text | 2.1 App Completeness | Very common | Test a fresh install on a real device; click every link |
| Reviewer can’t log in | 2.1 | Very common | Add a working demo account in review notes; keep the backend on |
| Repackaged website or too little to do | 4.2 Minimum Functionality | Common for web-based apps | Add account features, saved data, notifications, native navigation |
| Missing or broken privacy policy | 5.1.1(i) | Common | Link a live policy in App Store Connect and in the app |
| No in-app account deletion | 5.1.1(v) | Common for apps with sign-up | Add a delete-account option in settings |
| Screenshots don’t show the app in use | 2.3.3 | Occasional | Use real screens, not splash or login screens |
Apple reviewed about 9.1 million app submissions in 2025 and rejected about 2.1 million of them. Most first-time rejections aren’t about bad ideas. They come from a short list of fixable problems: a login the reviewer can’t get past, a placeholder screen, a privacy policy link that 404s, an app that is really a website, or a missing way to delete an account. This guide walks through the guidelines that catch new developers, quotes what Apple actually asks for, and ends with a checklist you can run the day before you press Submit.
What Apple’s numbers say about rejections
Apple publishes an annual App Store Transparency Report. The 2025 edition says App Review looked at 9,100,620 submissions and rejected 2,093,244. That is roughly 23% by our own arithmetic, so about one submission in four or five comes back at least once.
The same report shows 387,087 submissions approved after a rejection. In other words, a large number of rejected builds are fixed and accepted. A rejection message is a list of things to change, and most first-time developers get through on the second or third try once they know what reviewers are looking for.
| Guideline section | Rejections in 2025 | What it covers |
|---|---|---|
| Performance (2.x) | 1,354,418 | Completeness, accurate metadata, hardware and software compatibility |
| Legal (5.x) | 495,673 | Privacy, data use, intellectual property |
| Design (4.x) | 415,532 | Copycats, minimum functionality, spam |
| Business (3.x) | 283,820 | Payments and in-app purchase |
| Safety (1.x) | 151,159 | Objectionable content, user-generated content, developer information |
Performance rejections dominate
Performance, the section that contains guideline 2.1, accounts for more rejections than the next three sections combined. Apple’s App Review page backs this up from the other side: “On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness.” The good news is that completeness problems are the easiest to prevent, because you can find nearly all of them yourself before a reviewer does.
One submission can hit several guidelines
Apple notes that a single submission can be counted under more than one section. In practice, first rejections often cite two or three guidelines at once, for example a broken support link (2.1) plus a missing account deletion option (5.1.1(v)). Fix every item in the message before you resubmit, not just the first one.
Guideline 2.1: the app has to be finished
Guideline 2.1(a) asks for “final versions with all necessary metadata and fully functional URLs,” with no placeholder text and no empty websites. Reviewers install your build on a real device and use it. Anything that would embarrass you in front of a customer will probably be found.
Crashes and dead ends
The reviewer’s device may run a newer iOS version than yours, may be an iPad if your app supports iPad, and starts from a clean install with no cached data. Test exactly that: delete the app, reinstall from TestFlight and go through sign-up, the main feature and sign-out. Empty states matter here. A list screen that shows nothing and offers no next step reads as broken.
Demo accounts and sleeping backends
If your app has a login, 2.1(a) tells you to provide a demo account “and turn on your back-end service!” The exclamation mark is Apple’s. Put the username and password in the App Review Information section of App Store Connect, make sure that account has realistic data in it, and don’t change its password while the build is in review.
If sign-in uses a one-time code sent by email or SMS, the reviewer can’t receive it. Give them an account that can sign in another way, or explain in the notes how they can get in. Apple allows a built-in demo mode instead of a demo account only with prior approval.
Broken links and placeholder content
Apple’s App Review page lists broken links among the common issues and says that a link to user support and a link to your privacy policy are required for all apps. Click both from a phone that isn’t logged into anything. Search the app for “lorem ipsum,” “TODO,” “test” and sample product names before you upload.
Guideline 4.2: “beyond a repackaged website”
This is the rejection most likely to surprise people who start from a website or a web-based builder. Guideline 4.2 says an app “should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or ‘app-like,’ it doesn’t belong on the App Store.” Guideline 4.2.2 adds that apps “shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.”
What reviewers read as “app-like”
Apple doesn’t publish a checklist, so this is judgment. In our reading, the safest signals are things a bookmark can’t do: a signed-in account with the person’s own data, content they create or upload, notifications tied to something that matters to them, and navigation that behaves like a phone app (a tab bar, back gestures, no browser-style header). A restaurant app that shows the menu and opening hours is a website. One that lets regulars order ahead, save favorites and get a notification when the order is ready is an app.
Being web-based is not itself the problem
Many approved apps render part of their interface with web technology. What 4.2 targets is an app that adds nothing to the website it wraps. If your app is built from a web codebase, the question to ask is what a person can do in the app that they couldn’t do as well in Safari.
Guideline 4.3: spam, copies and crowded categories
Guideline 4.3(a) asks developers not to submit several bundle IDs of the same app. Apple’s own example is one app per city or per client; it suggests a single app with the variations inside it. Guideline 4.3(b) says not to submit apps that are “indistinguishable from what’s already widely available,” and names dating, flashlight, sound effects, wallpaper, simple timer and fortune-telling apps as categories it won’t accept without “a meaningfully different or improved experience.”
If you build apps for clients
Agencies and freelancers often meet 4.3 when they publish near-identical apps for different gyms, salons or churches from their own developer account. Each client should normally publish under its own Apple Developer account, so each app is clearly a different business’s product. Apple’s App Review page also lists “submitted by the wrong entity” as a common issue, and says apps for banking, crypto, healthcare, gambling and air travel must be submitted by the legal entity that provides the service.
Privacy rejections: policy links, deletion and purpose strings
Privacy items are the second big cluster. They are also mechanical, which makes them easy to get right once you know the rules.
Privacy policy (5.1.1(i))
“All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner.” The policy has to say what data the app collects, how, and what it is used for, confirm that third parties you share data with protect it equally, and explain retention, deletion and how people withdraw consent. A generic template that mentions none of your actual data is a common reason for a second rejection.
Account deletion (5.1.1(v))
“If your app supports account creation, you must also offer account deletion within the app.” Apple’s support page on account deletion adds detail: the option should be easy to find, usually in account settings; temporarily deactivating the account isn’t enough; a direct link to a web page that completes deletion is allowed; and requiring a phone call or email is not, except for highly regulated industries. If the person has an auto-renewing subscription, tell them that billing continues through Apple until they cancel it.
Purpose strings and permission requests
When your app asks for the camera, location, contacts or photos, iOS shows the text you supplied explaining why. Apple lists unclear purpose strings among common issues. “This app needs camera access” is weak. “Take a photo of your receipt to attach it to an expense” tells the reviewer and the user exactly why. Guideline 5.1.2 also says apps can’t require people to turn on push notifications, location or tracking in order to use the app.
Data sent to AI services
The October 2026 version of guideline 5.1.2 says you must clearly disclose where personal data will be shared with third parties, “including with third-party AI,” and get explicit permission before doing so. If your app sends user text or photos to an AI model hosted by another company, say so in the app before the first request and in your privacy policy.
Metadata and screenshot rejections
Guideline 2.3 asks that your description, screenshots, previews and privacy information “accurately reflect the app’s core experience.” A few specific rules catch first-time developers.
- 2.3.3: screenshots must show the app in use, not “merely the title art, login page, or splash screen.”
- 2.3.4: app previews may only use video screen captures of the app itself.
- 2.3.7: the app name is limited to 30 characters, with no keyword stuffing, trademarks you don’t own or prices.
- 2.3.10: no names or imagery of other mobile platforms, such as an Android phone frame in your iPhone screenshots.
- 2.3.1: new features must be described with specificity in the Notes for Review; generic descriptions will be rejected.
Payments and sign-in rules that change your design
Two guideline areas are worth reading before you build, because fixing them after a rejection can mean redesigning screens.
In-app purchase (3.1.1 and 3.1.3)
If your app unlocks digital features or content, such as premium tools or a subscription to articles, guideline 3.1.1 says it must use Apple’s in-app purchase. Physical goods and services used outside the app, such as a class booking, a haircut or a delivery, must use other payment methods under 3.1.3(e). On the United States storefront, the current guidelines also allow buttons and links to outside purchasing without a special entitlement; other storefronts still need the StoreKit External Purchase Link Entitlement. Decide which rule applies to what you sell before you design the paywall.
Third-party login (4.8)
If the main account uses a third-party or social login such as Google or Facebook, guideline 4.8 asks you to also offer an equivalent login option that limits data collection to name and email, lets people keep their email private and doesn’t collect interactions for advertising without consent. Sign in with Apple meets that description. Apps that use only their own email-and-password account system are exempt.
Common mistakes when responding to a rejection
How you respond matters almost as much as what you submitted.
- Arguing instead of fixing. If the reviewer couldn’t log in, the answer is a working account, not an explanation of why it should have worked.
- Fixing only the first item in the message and resubmitting. Each round trip adds a day or more.
- Resubmitting with no note. Reply in App Store Connect saying what changed and where to find it.
- Uploading a new build when only metadata was cited. Screenshot and description problems can usually be fixed without a new binary.
- Changing the demo account password, or letting the backend go to sleep, between submissions.
- Ignoring the appeal route when you disagree. Apple lets you appeal a decision to the App Review Board; use it for genuine misunderstandings, not for rules you hoped didn’t apply.
A pre-submission checklist
Run this the day before you submit. It takes an hour and covers most of the rejections above.
- Delete and reinstall the TestFlight build on a real iPhone; complete sign-up, the main task and sign-out without help.
- If you support iPad, repeat on an iPad or confirm the layout doesn’t break.
- Open the support URL and privacy policy URL on a logged-out phone.
- Find and remove placeholder text, test data and sample images.
- Confirm in-app account deletion works and actually deletes the account.
- Rewrite every permission prompt so it names the specific feature that needs it.
- Put a demo account with realistic data in App Review Information, plus two sentences on what the app does.
- Check that screenshots show real screens from this build.
- Decide which payment rule applies to anything you sell.
If you’d rather not do this yourself
Builders can take the build and upload work off your hands, though none can promise approval. Floot, for example, builds an app from a plain-English description with sign-up, login and a database, then builds and submits the native iOS and Android versions with your own developer accounts, no Mac needed. You still own the review notes, the demo account and the decisions above.
Frequently Asked Questions
What is the most common reason apps get rejected from the App Store?
App completeness under guideline 2.1. Apple says over 40% of unresolved issues relate to it on average: crashes, broken links, placeholder content and missing demo account details.
How long does it take to get approved after a rejection?
Resubmissions go back into the normal queue. Apple says it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours, so one fix-and-resubmit cycle usually costs a day or two plus your own fixing time.
Can I appeal an App Store rejection?
Yes. You can reply to the reviewer in App Store Connect to clarify, and if you believe the guideline was applied incorrectly you can submit an appeal to the App Review Board. Most first rejections are faster to fix than to appeal.
Will Apple reject an app that uses a web view?
Not automatically. Guideline 4.2 targets apps that are essentially a repackaged website with nothing app-like added. Apps that use web technology but offer accounts, saved data, notifications and native navigation are approved regularly.
Does every app need a privacy policy, even if it collects nothing?
Yes. Guideline 5.1.1(i) says all apps must link a privacy policy in App Store Connect and inside the app. If you collect nothing, the policy can say so, but the link must work. This is general information, not legal advice.
Do I have to add Sign in with Apple?
Only in some cases. Guideline 4.8 applies when your app uses a third-party or social login for the main account; then you must also offer an equivalent privacy-friendly login option, which Sign in with Apple satisfies. Apps that use only their own account system are exempt.
Sources
- Apple Developer, App Review Guidelines, 2026 https://developer.apple.com/app-store/review/guidelines/
- Apple Developer, App Review (review times and common issues), 2026 https://developer.apple.com/distribute/app-review/
- Apple, App Store Transparency Report 2025 https://www.apple.com/legal/app-store/transparency/2025/
- Apple Developer, Offering account deletion in your app, 2026 https://developer.apple.com/support/offering-account-deletion-in-your-app/