The most common App Store rejection reasons (and how to fix each)

Few things sting like getting your app rejected after weeks of work. The good news: rejections are rarely random. Apple reviewed around 7.77 million submissions in a recent year and rejected roughly a quarter of them — and somewhere between 40% and 60% of first-time submissions get bounced. But nearly all of those rejections are predictable, documented in Apple's guidelines, and avoidable with a little preparation. Here are the most common reasons apps get rejected and how to fix each one.

1. Crashes and bugs (Guideline 2.1)

This is the single most common rejection reason, and it's almost always preventable. If the reviewer hits a single crash, frozen screen, or button that leads nowhere, your app is rejected immediately — even if it runs perfectly on your own device.

Fix: Test thoroughly on real devices via TestFlight, not just the simulator. Walk through every screen and every button as if you were the reviewer. Pay special attention to fresh installs and edge cases like no network connection.

2. Inaccurate metadata (Guideline 2.3)

Your metadata is a promise. If your description, screenshots, or price don't match what the app actually does, you get rejected. A mismatch as small as listing $4.99 but charging $5.99 has delayed launches by days. Placeholder text, "coming soon" banners, and temporary images all trigger this too.

Fix: Make sure every claim matches reality. No placeholders, no features in the description that aren't in the build, and prices that match App Store Connect exactly.

3. Misleading or low-quality screenshots

This is a big one, and it's where a lot of indie developers slip up. Screenshots that show features that don't exist, fake UI, or mockups of things you haven't built will get flagged under inaccurate metadata. Low-resolution or broken-looking screenshots fall under design violations.

Fix: Every screenshot must come from your actual app. You can absolutely add captions, backgrounds, and device frames to make them look polished — that's expected — but the app UI shown has to be real and represent what users will actually get. If you need to produce clean, correctly-sized screenshots from your real app screens, our screenshot editor builds the full set in every required dimension, free and in your browser.

4. Minimum functionality & WebView wrappers (Guidelines 4.2, 4.3)

Apple rejects apps that are too simple, too similar to existing apps, or essentially a website loaded in a WebView with no native value. Design violations — including copycats and minimal-functionality apps — accounted for hundreds of thousands of rejections in a single year.

Fix: If you're wrapping web content, add genuine native features — push notifications, offline mode, camera or photo integration, a share extension. If Safari can do everything your app does, Apple will ask why the app needs to exist. Differentiate in features, UI, or content.

5. Privacy problems (Guideline 5.1)

With privacy enforcement tightening every year, apps that don't clearly disclose what data they collect — or whose privacy policy link is broken — get rejected fast. The privacy nutrition label and your actual data practices have to line up.

Fix: Provide a working privacy policy URL, complete your App Privacy details accurately, and make sure your privacy manifest matches what your app and its SDKs actually collect. If you don't have a policy yet, our privacy policy generator creates one tailored to your app for free.

6. In-app purchase rules (Guideline 3.1.1)

If you sell digital goods or subscriptions, Apple requires you to use its in-app purchase system. A "Subscribe" button that opens an external Stripe checkout in Safari is a classic rejection — even if it unlocks content inside your app. The price on your paywall must also exactly match App Store Connect.

Fix: Use StoreKit for digital purchases. Physical goods and services (ride-hailing, food delivery) are exempt. If you qualify for an external-payment entitlement in your region, follow Apple's exact disclosure requirements.

7. Missing Sign in with Apple, permissions, and background modes

Several smaller but frequent triggers: offering third-party login (Google, Facebook) without also offering Sign in with Apple; requesting permissions you don't use; or declaring background modes (audio, location) your app doesn't genuinely need. Apple checks — if you declare audio background mode but never play audio, you're rejected.

Fix: Only request what you use. Add Sign in with Apple if you offer any other social login. Declare only the background capabilities your app actually relies on.

What to do when you get rejected

A rejection isn't the end — it's a specific, fixable note. Apple's rejection notices cite the exact guideline, describe what the reviewer saw, and often include screenshots. The biggest mistake is panicking and changing everything:

• Read the actual guideline cited. Don't guess — Apple tells you exactly what failed.
• Make surgical fixes only. Fix the cited issue and nothing else. Resist the urge to clean up unrelated code or ship a new feature — every extra change adds risk and re-test surface.
• Reply in the Resolution Center. Don't just resubmit silently. Explain specifically what you changed and why it now complies. This often speeds up the next review.

The takeaway

Around 95% of rejections are predictable and avoidable. Most come down to the same handful of issues: test on real devices, make your metadata and screenshots honest, add real native value, get your privacy disclosures right, and use IAP where required. Run through these before you submit and you'll skip the rejection-and-resubmit cycle that costs other developers weeks.

Two of the most common rejection triggers — misleading screenshots and missing privacy policies — are exactly the parts of your listing you fully control. For the broader pre-submission picture, see our app launch checklist.