Why Apps Get Rejected by the App Store, and How to Avoid It

A rejection from App Review rarely kills an app. What it does is cost you days: you fix the issue, resubmit, and wait in the queue again — often while a launch date, a marketing push or an investor demo slides with it. Most rejections are predictable, and almost all of them trace back to a short list of guidelines.

This is that list, in the order we would check it before any submission. The guideline numbers refer to Apple’s App Review Guidelines, which change several times a year — when in doubt, read the current version rather than trusting a summary, including this one.

1. The app crashes or looks unfinished (Guideline 2.1)

App Completeness is the most common reason for rejection, and it is the easiest to avoid. Reviewers test on real devices, often on a newer iOS version than you developed against and on a network you do not control. A crash on launch, a blank screen while an API times out, a button that does nothing or a screen with placeholder text is an instant rejection.

• Test the exact build you submit, on the oldest and newest iOS versions you support.
• Test with a slow or flaky connection, and with permissions denied.
• Make sure the production backend is live and stable during review. A staging server that sleeps overnight has rejected more apps than bad code.
• Remove every “coming soon”, lorem ipsum and test account from the build.

2. The reviewer cannot get in

If your app requires an account, the reviewer needs one. Provide working demo credentials in the App Review notes in App Store Connect — with data already in the account, so they can see the app doing what it is for. If your app needs special hardware, a QR code, a location or an invite to function, explain that in the notes and give them a way through.

An app the reviewer cannot use is treated as an app that does not work.

3. No way to delete an account (Guideline 5.1.1(v))

If users can create an account in your app, they must also be able to start deleting it from inside the app. A link to email support is not enough, and neither is deactivation. This has been enforced since mid-2022 and still catches teams who built sign-up first and left deletion for later.

Deleting an account means deleting the associated data too, unless you are legally required to keep it — and if you offer Sign in with Apple, you should revoke the user’s token when they delete. Google Play has a matching requirement, so build it once for both.

4. Privacy: policies, labels, manifests and purpose strings

Privacy is now the broadest category of rejection, because it spans the app, its metadata and every SDK you include.

• A privacy policy must be linked in App Store Connect and reachable inside the app.
• The App Privacy labels must match what the app actually collects — including what your analytics, crash reporting and ad SDKs collect on your behalf.
• Privacy manifests. Since May 2024, apps and the third-party SDKs they include must declare why they use certain system APIs (such as file timestamps or UserDefaults) in a privacy manifest. An outdated SDK without one can get your upload rejected before a human ever sees it. Updating your dependencies is usually the fix.
• Permission purpose strings must say specifically why you need access. “This app needs your location” will be rejected; “Your location is shared with your chosen contacts only while a safety timer is running” will not.
• Respect a refusal. The app must keep working, as far as it reasonably can, when a user declines a permission. Do not block the whole app behind a camera prompt.
• App Tracking Transparency. If you or an SDK track users across other companies’ apps or websites — most ad networks do — you need the ATT prompt before tracking.

5. Selling digital things without In-App Purchase (Guideline 3.1)

If users pay to unlock digital content or features inside the app — subscriptions, premium tiers, coins, extra storage — that payment generally has to go through Apple’s In-App Purchase. Physical goods and real-world services are the opposite: they must not use In-App Purchase.

Rules on linking out to a web checkout have changed in some regions, notably the United States and the EU, and are still moving. We cover the full decision in In-App Purchase, Stripe or Stripe Connect?. For review purposes, the common failures are simpler:

• No “Restore Purchases” option for subscriptions and non-consumable purchases.
• Unclear subscription terms. Before purchase, the user must see what they get, the price, the billing period, and links to your terms of use and privacy policy.
• In-app purchases not submitted alongside the build that uses them, so the reviewer sees an empty paywall.

6. Third-party login without an equivalent option (Guideline 4.8)

If you offer sign-in through Google, Facebook or another third-party service, Apple requires you to also offer a login option that limits data collection to name and email, lets users keep their email address private, and does not track them for advertising without consent. Sign in with Apple meets that requirement, which is why most apps simply add it.

Apps that use only their own email-and-password accounts are not affected.

7. User-generated content without moderation (Guideline 1.2)

Social, chat, marketplace and community apps get extra scrutiny. If users can post content that other users see, Apple expects:

• A way to report offensive content.
• A way to block abusive users.
• A method for filtering objectionable material, and a commitment to act on reports promptly.
• Contact information so people can reach you.

These are much easier to design in from the start than to bolt on after a rejection. The voice and messaging apps we build, such as Leklok and Chattick, treat reporting and blocking as core features rather than settings-page afterthoughts.

8. Not enough app (Guidelines 4.2 and 4.3)

An app that is essentially a website in a wrapper, or a single feature that would be better as a web page, can be rejected for Minimum Functionality. Apps that are near-copies of other apps — including several versions of your own app for different cities or clients — can be rejected as spam.

The answer is native value: offline behaviour, push notifications, device features, a genuinely app-shaped workflow. If your product really is a website, a good mobile web experience may serve you better than a fight with App Review.

9. Metadata that does not match the app (Guideline 2.3)

Screenshots must show the app actually in use, not marketing art alone. The description must describe what the app does today, not the roadmap. The app name is limited to 30 characters and should not be stuffed with keywords. Every feature you mention should be reachable by the reviewer.

If your app runs on iPad — and iPhone apps do by default — reviewers may test it there. Check that your layouts hold up on an iPad screen before they do.

10. Background modes that are not justified

Requesting background location, audio or VoIP capabilities without an obvious, user-facing reason is a common rejection. Each background mode needs a feature the reviewer can see working. For calling apps, incoming VoIP pushes must be reported to CallKit as calls — iOS enforces this at runtime, not only at review.

Google Play has its own checklist

Google’s review is mostly automated and faster, but it has hard gates of its own:

• Closed testing for new personal developer accounts. Newer personal accounts must run a closed test with a minimum number of testers for a set period before they can publish to production. Plan for it; it cannot be rushed.
• The Data safety form must match what the app and its SDKs collect.
• Target API level. New apps and updates must target a recent Android version, and the bar rises every year.
• Account deletion, both in the app and through a web link listed on the store page.
• Native library compliance, such as the 16 KB page size requirement that blocks releases with outdated native code.

If you are rejected anyway

Read the rejection carefully: it names the guideline and usually explains what the reviewer saw. Then:

• If you misunderstood the rule, fix it and resubmit with a note in the App Review notes explaining what changed.
• If the reviewer misunderstood the app, reply in App Store Connect with a clear explanation and, ideally, a short screen recording. Many rejections are resolved this way without a new build.
• If you genuinely disagree, you can appeal to the App Review Board. Keep it factual.

Whatever happens, do not resubmit the same build unchanged hoping for a different reviewer. It wastes a cycle and rarely works.

The cheapest fix is a pre-submission check

Every rejection above is visible before you submit if someone looks for it. We run the build through QA against this list before it reaches the review queue, because a rejected build costs days and a broken payment flow costs customers. Store submission is part of every mobile app we build — the work ends in the store, not at a handover call.