How to Avoid App Store Rejection: 12 Common Reasons (2026)

Short answer: Most App Store rejections are avoidable. Ship a build that does not crash, give the reviewer a working demo account with your backend switched on, remove every placeholder, make sure the app does more than wrap a website, add in-app account deletion and a privacy policy link, and sell digital features only through In-App Purchase. Apple's own App Review Guidelines open with a checklist of "common missteps", and the rest are spelled out in specific guidelines quoted below.

Every number and quote below comes from Apple's or Google's own pages, checked on 12 Nov 2026. Advice is ours and is marked as such.

TL;DR#

• About one submission in four is rejected. Apple's 2025 Transparency Report lists 9,100,620 submissions reviewed and 2,093,244 rejected. 387,087 were approved after a rejection.
• Performance problems dominate. 1,354,418 rejections were under the Performance section, more than Legal, Design, Business and Safety combined.
• Guideline 2.1 is the cheap win. Crashes, placeholder text, dead links, no demo account and an offline backend are all 2.1.
• Two rules catch indie apps late: in-app account deletion (5.1.1(v)) and In-App Purchase for anything you unlock (3.1.1).
• Rejected? Reply in App Store Connect, fix everything at once, appeal only with specific reasons.

Disclosure: ZeroRaised is a launch site for bootstrapped products and has no relationship with Apple or Google. This is not legal advice, and Apple's guidelines change: read the current version before you submit.

What Apple's numbers say about rejections#

Apple publishes an App Store Transparency Report each year. The 2025 report gives these figures:

Apple notes that "App submissions may be rejected for noncompliance with one or more guidelines", so section counts overlap, and that apps may be submitted multiple times, so these are submissions, not unique apps.

Our arithmetic: 2,093,244 divided by 9,100,620 is about 23%. Performance is section 2 of the guidelines, home of App Completeness and Accurate Metadata: problems you can catch yourself.

The 12 most common rejection reasons and how to avoid them#

Our selection, built on Apple's "common missteps" checklist. Quotes are from the current App Review Guidelines.

1. Crashes and obvious bugs (2.1)#

Guideline 2.1(a): "We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems."

Fix: test the release build on a real device with the oldest iOS you support. Clean install, deny every permission once, go offline mid-session. Reviewers hit first-run states you stopped seeing weeks ago.

2. No demo account, or a backend that is off (2.1)#

The guidelines ask you to "include demo account info (and turn on your back-end service!) if your app includes a login."

Fix: a dedicated reviewer account with data already in it and paid access if needed, credentials in App Review Information, and no scale-to-zero servers during the review window.

3. Placeholder content and broken links (2.1)#

Submissions "should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission."

Fix: search the project for "lorem" and "TODO", and open your support, marketing and privacy URLs on a phone.

4. In-App Purchases the reviewer cannot find (2.1(b))#

"If you offer in-app purchases in your app, make sure they are complete, up-to-date, visible to the reviewer and functional." If a configured product cannot be reached in the build, Apple asks you to "explain the reason in your review notes."

Fix: submit the IAP products with the version, test them in sandbox, and check that the paywall and restore button both show for the demo account.

5. Metadata that does not match the app (2.3)#

Guideline 2.3.3: "Screenshots should show the app in use, and not merely the title art, login page, or splash screen." And 2.3.7: "App names must be limited to 30 characters."

Fix: screenshot only features in this build, and cut "coming soon" promises from the description.

6. Vague review notes (2.3.1)#

Guideline 2.3.1(a) says new features "must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected)".

Fix: write numbered steps: log in with this account, tap this tab, scan this sample code. If a feature needs hardware or a location, say how to see it without one.

7. A repackaged website (4.2)#

"Your 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."

Fix: our read is that a WebView shell of your SaaS is the riskiest first submission an indie developer can make. Add what a website does badly: offline access, useful notifications, widgets, camera or share sheet input.

8. Spam and copycat apps (4.3)#

Guideline 4.3(a): "Don't create multiple Bundle IDs of the same app". Guideline 4.3(b): "Don't submit apps that are indistinguishable from what's already widely available."

Fix: one app per idea, with variants as settings. In a crowded category, make the difference visible on the first screen and name it in review notes.

9. Missing privacy policy (5.1.1(i))#

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."

Fix: link it from Settings and in App Store Connect, covering every SDK you ship. Our guide on how to write a privacy policy for a SaaS covers what to include.

10. No in-app account deletion (5.1.1(v))#

Apple's account deletion page says: "Apps submitted to the App Store that support account creation must also let people initiate deletion of their account within the app." It adds that "only offering to temporarily deactivate or disable an account is insufficient", and apps with Sign in with Apple "should use the Sign in with Apple REST API to revoke user tokens."

Fix: a Delete account button in settings, a confirmation step and a server job that really deletes the data.

11. Payments that skip In-App Purchase (3.1.1, 3.1.2)#

Guideline 3.1.1: "If you want to unlock features or functionality within your app ... you must use in-app purchase." It rules out "license keys" and "QR codes" among other unlock mechanisms. For subscriptions, 3.1.2(a) requires "ongoing value" and a period of "at least seven days", and 3.1.2(c) says "you should clearly describe what the user will get for the price."

Fix: sell digital features with StoreKit and show price, period and what is included on the paywall.

12. Social login without an equivalent option (4.8)#

Apps using "a third-party or social login service" for the primary account "must also offer as an equivalent option another login service" that meets Apple's privacy conditions, such as limiting data to name and email. Apps using only their own account system are exempt.

Fix: if you offer Google sign-in, add Sign in with Apple at the same level, or use email and password only.

Rejection to guideline to fix: quick table#

Printable pre-submission checklist#

Copy this into your release notes and tick every line.

• Release build tested on a real device, clean install, oldest supported iOS
• No crashes with permissions denied or no network
• Demo account in App Review Information, with data and paid access
• Backend live and not scaled to zero for the review window
• No placeholder text; support, marketing and privacy URLs all load
• Contact information in App Store Connect is current
• Screenshots show this build in use; name is 30 characters or fewer
• Review notes explain non-obvious features and every IAP step by step
• IAP products submitted with the version and tested in sandbox, restore works
• Paywall states price, period and what the user gets
• Privacy policy linked in App Store Connect and inside the app
• Privacy details answers include every third-party SDK
• Privacy manifest declares any required reason APIs (yours and your SDKs')
• In-app account deletion works end to end
• Sign in with Apple or an equivalent offered if you use social login
• Only public APIs; no code downloaded that adds features
• If users post content: filter, report, block and published contact details
• Release option set to manual so approval does not pick your launch day

The privacy manifest line is an upload blocker rather than a review rejection. Apple's required reason API documentation says: "Starting May 1, 2024, apps that don't describe their use of required reason API in their privacy manifest file aren't accepted by App Store Connect." SDKs must declare their own use, so update old SDKs first.

On the 1.2 line, Apple requires user-generated content apps to include "A method for filtering objectionable material" and "The ability to block abusive users from the service", plus reporting and published contact details.

What to do after a rejection#

1. Read the full message in App Store Connect. Note every guideline cited, not just the first.
2. Ask if anything is unclear. The guidelines point you to App Store Connect to talk to the App Review team directly.
3. Fix everything in one pass. The guidelines warn that repeated rejections for the same guideline make review take longer.
4. Reply with specifics. What you changed, where the reviewer sees it, updated demo steps.
5. Appeal only if Apple is wrong. Apple's App Review page says you "may choose to submit an appeal to the App Review Board", and asks you to "Submit only one appeal per submission that didn't pass review" with "specific reasons why you believe your app complies with the App Review Guidelines."
6. Expedite only for real emergencies. You can request it "if you face extenuating circumstances". For a critical bug, "include the steps to reproduce the bug on the current version of your app."

On timing, the same page says Apple typically reviews "at least 50% of submissions in less than 24 hours" and 90% in less than 48 hours. Our App Store launch guide covers planning a launch around that.

The Google Play angle, briefly#

Google's first hurdle is testing rather than review. Its Play Console Help page says personal accounts created after November 13, 2023 must run a closed test "with a minimum of 12 testers" who have been "opted in continuously for at least 14 days", before you can "apply for production access". Recruit testers early. Our guide on how to publish an app on Google Play walks through it.

Frequently asked questions#

What is the most common reason for App Store rejection?#

In Apple's 2025 App Store Transparency Report, the Performance section of the guidelines accounted for 1,354,418 rejections, far more than any other section. Performance is section 2, which includes 2.1 App Completeness (crashes, placeholder content, missing demo accounts) and 2.3 Accurate Metadata.

How long does App Review take?#

Apple's App Review page says it works around the clock, typically reviewing at least 50% of submissions in less than 24 hours and 90% in less than 48 hours. It also says incomplete submissions may be delayed or may not pass, and the guidelines warn that repeated rejections for the same guideline make review take longer.

Can I appeal an App Store rejection?#

Yes. Apple's App Review page says you may submit an appeal to the App Review Board, asks you to submit only one appeal per submission that did not pass, and to give specific reasons why you believe the app complies with the guidelines. For questions or extra information, reply to App Review in App Store Connect first.

Do I need account deletion in my app?#

If your app supports account creation, yes. Apple's account deletion page says such apps must let people initiate deletion of their account within the app, that only offering to deactivate or disable an account is insufficient, and that apps supporting Sign in with Apple should use its REST API to revoke user tokens.

Is Google Play review easier for a first app?#

It is different rather than easier. Google's Play Console Help says personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in continuously for at least 14 days before applying for production access.

Approved? Now launch it#

Once Apple says yes, hold the release and plan the launch with our bootstrapped app launch guide. ZeroRaised is a launch directory for products built without institutional VC: submit your app for free. For more launch checklists for indie makers, join the ZeroRaised newsletter.

Sources#

• App Review Guidelines, Apple Developer, last checked 12 Nov 2026
• App Store Transparency Report 2025, Apple, last checked 12 Nov 2026
• App Review, Apple Developer, last checked 12 Nov 2026
• Offering account deletion in your app, Apple Developer, last checked 12 Nov 2026
• Describing use of required reason API, Apple Developer Documentation, last checked 12 Nov 2026
• App testing requirements for new personal developer accounts, Play Console Help, last checked 12 Nov 2026