App Store Rejection Reasons and How to Fix Them

Common App Store rejection reasons under the App Review Guidelines, how to fix each one, and a pre-submission checklist to get your iOS app approved faster.

· 6 min

Most teams shipping their first iOS app see "Rejected" in App Store Connect at least once. App Store rejection reasons are rarely a mystery: they map to rules in Apple's App Review Guidelines, and most can be prevented before you submit. This article covers the most frequent rejections, how to fix them and a checklist to run before every submission.

Apple updates its guidelines and numbering from time to time. The sections below reflect the guidelines at the time of writing; always check the official App Review Guidelines for exact wording.

How App Review Works

Apple reviewers install your build on real devices, check metadata and privacy declarations, and assess compliance. If rejected, you receive the guideline number and a short explanation in the Resolution Center.

  • Metadata-only rejections can often be fixed without a new build.
  • Sometimes Apple just asks for more information; replying may be enough.
  • If you disagree, you can reply in the Resolution Center or appeal to the App Review Board.

The Most Common App Store Rejection Reasons

GuidelineTopicTypical cause
2.1App CompletenessCrashes, broken buttons, empty screens, missing demo account
2.3Accurate MetadataScreenshots or descriptions that do not match the app
4.2Minimum FunctionalityThin website wrappers with little native value
4.3SpamMany near-identical apps or template clones
3.1.1In-App PurchaseSelling digital content outside Apple's payment system
5.1.1Data Collection and StorageUnneeded permissions, no privacy policy, no account deletion

Guideline 2.1: App Completeness

The single most common reason. If the reviewer hits a crash, endless spinner or dead feature, the app is rejected.

  • Test on multiple devices and iOS versions through TestFlight.
  • Provide a working demo account with realistic content in App Review Information.
  • Keep your backend reachable during review.
  • Explain features that need special hardware or locations, ideally with a demo video.

Guidelines 4.2 and 4.3: Minimum Functionality and Spam

Apps that only display a website in a WebView, or offer very limited functionality, are usually rejected. Near-duplicate apps can be flagged as spam.

  • Add genuinely mobile value: notifications, offline use, device features, native UI.
  • Instead of one app per branch or client, consider a single app with a selector.
  • When replying, explain concretely how the app differs from your website.

These rejections usually trace back to product scope, which is why we assess platform fit at the start of every mobile app development project.

Guideline 3.1.1: In-App Purchase Rules

Digital content, subscriptions and premium features consumed in the app generally must use Apple's in-app purchase. Physical goods and real-world services are exempt. Links or prompts steering users to cheaper web purchases of digital content are a classic rejection. Some regions, such as the EU and the US, now have legally driven exceptions for external payments and links; these vary by country and program, so verify the current terms. Subscription screens must clearly show price, duration and renewal terms and offer Restore Purchases.

Guideline 5.1: Privacy and Data Collection

  • A privacy policy accessible in App Store Connect and inside the app.
  • Clear, specific permission purpose strings in Info.plist.
  • If users can create an account in the app, they must be able to initiate account deletion in the app.
  • Privacy labels that match real data collection, including third-party SDKs.
  • App Tracking Transparency permission if you track users across other companies' apps and sites.

Metadata and Design Issues

Showing features that do not exist, mentioning other platforms, or using "beta" wording in screenshots causes metadata rejections. Broken iPad layouts or designs that ignore Human Interface Guidelines can also cause trouble, so we run UI/UX design alongside development.

Pre-Submission Checklist

  1. Does a clean install of the final build launch without crashing?
  2. Does the demo account work, with content?
  3. Are there any dead buttons or "coming soon" screens?
  4. Are the privacy policy link and account deletion flow in place?
  5. Are permission texts clear and specific?
  6. Are digital sales handled through in-app purchase?
  7. Do screenshots and description match this version?
  8. Have you explained special cases in Review Notes?

If you are rejected, reply briefly and with evidence: what you changed and how the flagged screen now works, with a screenshot or video if useful. Resubmitting the same build without explanation usually gets the same result.

We use this checklist for our own apps. If your app was rejected or you are preparing a first submission, contact BernSoftware and we will help you read the rejection and plan the fix.

Frequently asked questions

How long does App Store review take?

Apple typically reviews most submissions within one to two days, but it can take longer during busy periods or when extra review is needed. No exact time is guaranteed.

What should I do if my app is rejected?

Read the Resolution Center message and the cited guideline carefully, fix the issue and resubmit with a new build or updated metadata. If you disagree, reply with an explanation or appeal to the App Review Board.

Will Apple accept a WebView app?

Apps that simply display a website are usually rejected under Guideline 4.2. The app needs to offer mobile-specific value such as notifications, offline use or device features.

Planning a project like this?

Plan it in 10 steps