App Store Rejection Checklist: 9 Checks Before You Submit

The common App Store rejections come from issues you can check yourself before submitting: crashes or placeholder content (Guideline 2.1), no working demo account, metadata that misdescribes the app (2.3), privacy gaps (5.1), no in-app account deletion, a social login without an equivalent option (4.8), digital goods sold outside In-App Purchase (3.1.1), and thin or duplicate apps (4.2, 4.3).

Each item is tied to its number in the App Review Guidelines, checked against the version Apple marks as last updated on 16 October 2026. Guidelines change — read the current text before relying on any one of them.

The checklist at a glance

Why was my app rejected? Start with Guideline 2.1

Most likely for something under App Completeness. Apple's App Review page says that, on average, over 40% of unresolved issues relate to Guideline 2.1 — crashes, placeholder content, incomplete information. Check the first two items most carefully.

1. Crashes, placeholders and broken links (2.1)

Apple expects a final version, tested on a device, with placeholder text and temporary content removed, and rejects builds that crash or show obvious technical problems.

• Install the exact build you are submitting on a physical iPhone with the current iOS and go through every main flow: sign-up, purchase, the core feature. If it runs on iPad, check there too.
• Search the app and listing for lorem, TODO, test and "coming soon" screens.
• Tap every link. Apple lists a working support link and a privacy policy link as required for all apps.

2. A demo account, a live backend and review notes (2.1)

If the app has a login, the reviewer needs one that works. Apple's guidance on a complete review is specific:

• Credentials must work at the time of submission; ones that expire before review starts can get it rejected.
• If you sell auto-renewable subscriptions, provide an account with an expired subscription so the whole purchase flow can be reviewed.
• If sign-in needs a one-time code, put it in the notes in advance.
• Keep the backend running during review. The Before You Submit list in the App Review Guidelines asks for backend services to be "live and accessible during review". A staging server switched off for the weekend can be enough for a rejection.

Under 2.1(b), every in-app purchase you configured must be visible and working; if one cannot be found in the app, explain why in the notes.

3. Metadata and screenshots that match the app (2.3)

The description, screenshots and previews must reflect the app's core experience. Two sub-rules catch most people:

• 2.3.3 — screenshots show the app in use, not just title art, a login screen or a splash screen.
• 2.3.10 — no names, icons or imagery of other mobile platforms. A "Get it on Google Play" badge in one screenshot is enough.

The second one, with a ten-minute check across localisations, is covered in Guideline 2.3.10: the metadata rejection explained.

Privacy: the items that need the most preparation

4. Privacy policy and permission texts (5.1.1)

Under 5.1.1(i), the privacy policy must be linked both in App Store Connect and inside the app, where it is easy to find. It must say what data you collect and how it is used, confirm that third parties you share it with protect it equally, and explain retention, deletion and how to withdraw consent.

Under 5.1.1(ii), every permission prompt — camera, location, contacts, photos — needs a purpose string that clearly explains why. Apple's App Review page suggests including an example of how the data will be used. Also check that the App Privacy answers in App Store Connect match what the app and its SDKs collect.

5. Tracking and App Tracking Transparency (5.1.2)

Linking your app's data with other companies' data for advertising or ad measurement, or sharing it with data brokers, is tracking. Guideline 5.1.2(i) requires permission through the App Tracking Transparency prompt first.

• Find out which SDKs (ads, attribution, analytics) track. Apple holds you responsible for them as if they were your own code.
• Show the ATT prompt, with a purpose string, before any tracking starts.
• Don't lock or reward anything based on the answer. Apple's FAQ says plainly that functionality cannot be gated on allowing tracking.

6. Account deletion inside the app (5.1.1(v))

If people can create an account in your app, Guideline 5.1.1(v) requires that they can delete it from within the app. Apple's account deletion guidance adds what usually causes the rejection:

• Deactivating an account is not enough — the account and its personal data must be deleted.
• The option must be easy to find, usually in account settings.
• Outside highly regulated industries, people should not have to phone, email or chat with support to finish.
• Auto-created "guest" accounts count too.
• A web page is fine if the link goes straight to where deletion is completed.

Login, payments and whether it counts as an app

7. Social login needs an equivalent option (4.8)

The wording here is often quoted from memory, and it has changed. Guideline 4.8 applies when the app uses a third-party or social login (Google, Facebook, X and others) for the user's primary account. In that case the app must also offer "as an equivalent option another login service" that:

• limits data collection to the user's name and email address;
• lets users keep their email address private;
• does not collect interactions with your app for advertising without consent.

The current text does not name Sign in with Apple, but it meets the three conditions, which is why it remains the usual answer. No second option is needed if the app uses only your own account system.

8. Digital goods through In-App Purchase (3.1.1)

Paid features or content used inside the app — subscriptions, premium content, a full version, game currency — must be sold through In-App Purchase. License keys, QR codes and other home-made unlocks are not allowed, and restorable purchases need a restore option.

The reverse also holds: physical goods and services used outside the app, such as deliveries or rides, must use other payment methods (3.1.3(e)). Linking out to other ways to pay depends on the storefront — as of October 2026, allowed on the United States storefront, elsewhere only with a specific entitlement or not at all — so check 3.1.1(a) for each market.

9. Enough functionality, and only one of it (4.2, 4.3)

Guideline 4.2 expects features, content and interface that make the app more than a repackaged website; a web view of your site or a collection of links will struggle. Under 4.2.6, apps generated from commercial templates are rejected unless the content provider submits them.

Guideline 4.3 covers spam: no separate bundle IDs for essentially the same app (one per city or per client), and no apps indistinguishable from what is widely available. Apple names saturated categories — dating, flashlight, wallpaper among them — where a new app needs a meaningfully different experience.

One check that happens before review: the privacy manifest

Not a guideline, but it stops submissions earlier. Since 1 May 2024, App Store Connect does not accept apps that use "required reason" APIs without declaring the reason in a privacy manifest (PrivacyInfo.xcprivacy). Apple's list of SDKs that must include a privacy manifest names Flutter itself and plugins such as shared_preferences_ios, path_provider and url_launcher. In an older Flutter app, update these packages before you upload.

If you were rejected: how to respond

1. Read the message in App Store Connect. It names the guideline. Many developers still call this place the Resolution Center; Apple's help now calls it replying to App Review. 2. If the reviewer misunderstood, reply there, specifically: the feature, the step, where to find it. You can also request a call; Apple says calls are typically completed within three to five business days. 3. If the issue is real, fix it and resubmit, saying in the notes what changed. 4. Appeal only if you believe the app complies. The App Review Board appeal comes after replying to the rejection: one appeal per rejected app, citing the guideline and showing point by point how the app meets it. Don't appeal something already fixed and resubmitted. 5. For an app already on the store, a bug-fix update is not held up by other guideline issues unless they are legal or safety ones — accept the Bug Fix Submission offer in App Store Connect and fix the rest next time.

Stuck in review, or starting from scratch?

DriveCode builds iOS & Android apps, Flutter-first. If the app is built but keeps bouncing between rejections — often because the team that built it has left — we take over the app: accounts and keys into your name first, then the fixes Apple asked for. If you are planning a new app, we build iOS and Android apps in Flutter, submitted from your own developer account; our own apps are live in both stores, so this list is part of every release we ship. If the developer has stopped answering, start with what to secure first.

Questions people ask

How long does App Review take? As of October 2026, Apple says it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 (App Review). Incomplete submissions, and repeated rejections for the same guideline, take longer.

Do I need Sign in with Apple? Not by name. If you offer a third-party login for the primary account, you need an equivalent option that meets the three conditions in 4.8; Sign in with Apple is the common way to meet them.

Can I explain the problem instead of fixing it? If the reviewer misunderstood the app, yes — reply in App Store Connect with specifics. If the problem is real, explaining it will not change the outcome.

Does Apple publish its own checklist? Yes: "Before You Submit" at the top of the App Review Guidelines, and "Avoiding common issues" on the App Review page. This article maps the most frequent items to the guidelines behind them.