Why apps get rejected by App Store review and how to fix it

Every app on the App Store is checked by Apple's App Review team before it goes live, and every update is checked again. A rejection is frustrating, especially when a launch date is riding on it, but it is rarely a disaster. Most rejections come from a short list of predictable problems, and most are fixed within days.

This guide covers the most common reasons, how to fix each one, and a real rejection we had ourselves in October 2026.

How often apps get rejected

Rejection is normal. In 2025, Apple reviewed 9,100,620 app submissions and rejected 2,093,244 of them, roughly 23% ^[1]. The same report shows 387,087 submissions approved after an earlier rejection ^[1]. Apple notes that one app may be submitted several times before approval, and that a submission can be rejected under more than one guideline ^[1].

By section of the guidelines, Performance was cited most often (1,354,418 rejections), followed by Legal (495,673), Design (415,532), Business (283,820) and Safety (151,159) ^[1].

Apple also says that, on average, over 40% of unresolved issues relate to guideline 2.1, App Completeness, which covers crashes, placeholder content and incomplete information ^[2]. The good news is that review itself is fast: Apple typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours ^[2].

The most common reasons, and the fix for each

1. Crashes, bugs and unfinished features (guideline 2.1)

Apple will reject "incomplete app bundles and binaries that crash or exhibit obvious technical problems" ^[3]. Apple asks you to "thoroughly test on devices running the latest software and fix all bugs before submitting" ^[2], so an app that works in the simulator can still fail.

Fix: test the exact build you submit on a physical device with the latest iOS. Walk every main flow, including first launch with no data, poor network and denied permissions.

2. Missing review information (guideline 2.1)

If your app has a login, Apple expects a working demo account, and asks you to "turn on your back-end service" ^[3]. If you sell in-app purchases, they must be complete, visible to the reviewer and working, and any that can't be found should be explained in the review notes ^[3]. Apple also says that if features need specific hardware or an environment that is hard to reproduce, you should be prepared to provide a demo video or the hardware ^[2].

Fix: fill in the App Review Information section of App Store Connect completely. Give a demo account that does not expire, and explain anything that isn't obvious: where to find the purchase screen, what hardware a feature needs, how to trigger a particular state.

3. Placeholder content and broken links

Apple lists placeholder text and images, and broken links, among its common rejection reasons. Every app needs a working support link with up-to-date contact information and a link to a privacy policy ^[2].

Fix: click every link in the app and the listing. Search the build for "lorem ipsum", "TODO" and test data.

4. Inaccurate metadata and screenshots (guideline 2.3)

Your description, screenshots, previews and privacy information must "accurately reflect the app's core experience" ^[3]. Screenshots of features that aren't in the build, or marketing images that hide what the app actually looks like, will get flagged.

Fix: take screenshots from the real build. If a feature is coming later, leave it out of the listing until it ships.

5. Privacy problems (guideline 5.1)

This is the area that catches the most careful teams. Common issues:

• A vague or missing privacy policy. Apple wants a policy that says what data the app collects, how and why; confirms that anyone you share it with protects it to the same standard; and explains how you keep and delete data and how people can withdraw consent or ask for deletion ^[2].
• Unclear permission requests. When asking for access to data, you must "clearly and completely describe how your app will use the data" ^[2].
• An inaccurate privacy label. You must declare your privacy practices in App Store Connect, including those of third-party code in your app, to submit new apps and updates ^[5].
• No account deletion. If your app lets people create an account, it must also let them delete it within the app ^[3].
• Manipulative permission screens. Apps "must not attempt to manipulate, trick, or force people to consent to unnecessary data access" ^[3]. Our own rejection fell under this one.

6. Payments outside in-app purchase (guideline 3.1.1)

If you unlock features or content inside the app, for example with subscriptions or a premium tier, you generally must use Apple's in-app purchase. Apps may not use their own mechanisms such as license keys or QR codes to unlock functionality, and restorable purchases need a restore mechanism ^[3].

Fix: review every paywall and upgrade path. Add a visible Restore purchases button.

7. Not enough value, or a website in a wrapper (guideline 4.2)

Apple expects apps to offer features, content and interface that "elevate it beyond a repackaged website" ^[3]. Its list of common reasons also calls out web clippings, copycats and repeated submission of near-identical apps ^[2].

Fix: if your app is mostly a website, add the things only an app can do well: offline access, notifications that matter, device features, a faster native interface. Or ask whether you need an app at all.

A worked example: our own rejection

We build and publish our own iOS apps, so we go through App Review like everyone else. Here is what happened with Cuefold, our teleprompter camera app, built in native Swift 6 and SwiftUI with on-device speech recognition and StoreKit 2 subscriptions.

8 October 2026: first submission. Three days after the first commit, we submitted version 1.0.

Information Needed (guideline 2.1). Rather than approving or rejecting, Apple asked for more information before reviewing. We were a new developer account with a camera app, so we recorded the app running on a real device, attached the recording to the submission, and explained in the review notes how to reach every feature, including the paywall. This lines up with Apple's own advice to be ready with a demo video when features need specific hardware ^[2].

15 October 2026: rejected under guideline 5.1.1(iv). Before iOS shows its system prompt for camera and microphone access, Cuefold shows a short screen explaining why it needs them. That is good practice. The problem was the button on that screen. It said "Allow camera and microphone".

The guideline itself is short: apps must not manipulate or trick people into consenting ^[3]. The specifics are in Apple's Human Interface Guidelines on privacy. They say that using a term like "Allow" on a custom pre-permission screen is a form of manipulation, because people may then tap the system alert's Allow button without meaning to. Apple asks you to use "a term like 'Continue' or 'Next'" for the single button on that screen, and not to add options that skip the system alert ^[4].

We had not tried to trick anyone; we simply used a natural label. But to a reviewer, our button looked like the system's own Allow button, which is exactly what the guidance warns against.

The fix. We changed the button to "Continue" in every language the app supports, rebuilt, and resubmitted. The app was approved on 16 October.

The lessons:

• Read the Human Interface Guidelines alongside the App Review Guidelines. Rejections often cite a short guideline whose detail lives in the HIG.
• Check every language. A fix in English only will fail again in the next review.
• Expect hardware apps to be asked for a demo video, and record one before you submit.

What to do when you are rejected

1. Read the message carefully. It names the guideline and usually describes what the reviewer saw. Look up the full guideline text and any related HIG page.
2. Reply if something is unclear. You can respond to App Review in App Store Connect to ask questions or give information the reviewer may have missed.
3. Fix the cause, not the symptom. If one permission screen was flagged, check every permission screen. If one link was broken, check them all.
4. Resubmit with a clear note. Explain briefly what you changed.
5. Appeal only if you believe Apple got it wrong. If you think the reviewer misunderstood your app or treated it unfairly, you can appeal to the App Review Board. Apple asks for specific reasons, one appeal per rejected submission, and answers to any outstanding information requests first ^[2].
6. Ask for an expedited review if you have a genuine reason. Apple considers expedited review for things like a critical bug fix or a launch tied to an event you are directly associated with ^[2].

If the developer who built your app is no longer around to make the fix, we can take over the app, get it approved and then keep it up to date on our App care plan.

A pre-submission checklist

• The exact build has been tested on a real device with the latest iOS.
• Demo account details, special instructions and hardware notes are in App Review Information.
• All in-app purchases are visible, working and restorable.
• Support and privacy policy links work.
• Screenshots come from the real build.
• The privacy label matches what the app and its third-party code actually collect.
• Every permission prompt explains its purpose, and any pre-permission screen has a single "Continue" or "Next" button.
• Account deletion is available in the app if accounts exist.
• No placeholder content anywhere, in any language.