App Store Review Rejection: The 12 Most Common Reasons iOS Apps Get Rejected and How to Fix Them

You shipped the build. You wrote the release notes. You told the team it would be live by Friday. Then App Review sends a message with a guideline number, a screenshot, and no real explanation. Welcome to the loop that costs founders entire sprints.

The frustrating part is that most app store rejection reasons are not about product quality. Apple is not telling you your app is bad. It is telling you a checkbox is missing, a demo account does not work, or your privacy answers do not match what your SDKs actually do. Below are the 12 rejections we see most often, the exact fix for each, and what you need to resubmit (a new binary or just metadata) so you do not waste another review cycle.

First: Metadata Rejected vs Binary Rejected

Before you touch Xcode, read the rejection carefully. Apple issues two very different types of rejection, and confusing them is the number one reason founders burn extra days.

Type	What it means	What you resubmit	Typical turnaround
Metadata Rejected	The build is fine. Something in App Store Connect is wrong: screenshots, description, demo account, privacy URL, age rating, privacy labels.	Nothing. Fix the field in App Store Connect and reply in Resolution Center. No new build needed.	A few hours to 24h
Binary Rejected	Something in the app itself failed: a crash, a bug, a missing feature, a policy violation in the code.	A new build with an incremented build number, plus a reply explaining what changed.	24h to 72h

If you upload a new binary for a metadata rejection, you restart the clock for no reason. Read the header of the message first.

The 12 Most Common App Store Rejection Reasons in 2026

1. Guideline 2.1 Performance: Crashes, bugs and incomplete builds

This is the single most cited rejection. The reviewer opened the app on an iPad or on the latest iOS version, something broke, and the review ended there. Common triggers include crashes on launch, infinite loading spinners, buttons that do nothing, placeholder Lorem Ipsum text, and features that depend on a staging server you turned off.

The fix:

• Test the exact build you uploaded through TestFlight, not your debug build. They are not the same.
• Test on iPad even if your app is iPhone first. If it is not iPad compatible, set the device family correctly instead of shipping a broken iPad layout.
• Test on the newest public iOS release and on a device with a poor network connection.
• Make sure the backend the build points to is production, live, and will stay up during review.
• Remove every “coming soon”, greyed out tab, and placeholder asset.

What to resubmit: a new binary, plus a Resolution Center reply naming the fix and the build number. Ask for the crash log or screenshot if the reviewer did not attach one.

2. Guideline 2.1: Broken sign-in flows and missing demo accounts

If anything in your app sits behind a login, Apple must be able to get in. The classic failures are: a demo account that expired, an account with empty data so the reviewer sees blank screens, SMS or email two factor authentication the reviewer cannot pass, phone number verification restricted to one country, and OAuth logins that fail inside the review network.

The fix:

1. Create a permanent reviewer account that never expires and never gets wiped by a cron job.
2. Populate it with realistic data so every screen is meaningful.
3. If you use 2FA, either whitelist the reviewer account or provide a static bypass code in the App Review Information notes.
4. If sign-in needs a specific region, say so and provide a workaround.
5. Add a short walkthrough in the Notes field: where to tap, what to expect, how to reach the paid features.
6. Attach an App Review attachment video if any flow is non obvious (hardware pairing, B2B provisioning, invite codes).

What to resubmit: metadata only in most cases. Update the demo credentials, confirm you tested them that morning, and reply.

3. Guideline 2.3 Accurate Metadata: screenshots, description and previews

Your store listing must describe the app that actually exists. Rejections here come from screenshots showing features that are not in the build, screenshots that are mostly marketing text instead of real UI, device frames that do not match the required display sizes, descriptions mentioning unreleased features, keyword stuffing in the subtitle, and app previews recorded from a different app version.

The fix:

• Every screenshot must be captured from the submitted build and show real in-app content.
• Remove references to competitors, to “best” or “number one” claims you cannot support, and to features gated behind a waitlist.
• Keep the promotional text free of pricing claims that contradict your in-app purchase configuration.
• Check your support URL and marketing URL actually resolve. Dead links are an instant 1.5 or 2.3 rejection.

What to resubmit: metadata only.

4. Guideline 5.1.1 Data Collection: privacy policy and permission purpose strings

Two separate problems get grouped here. First, the privacy policy link must be live, publicly accessible without a login, and must actually describe your data practices. A 404, a Notion page set to private, or a generic template that mentions a different company name all get flagged. Second, every permission prompt needs a clear purpose string in your Info.plist. “This app needs camera access” is not enough. Say why.

The fix:

• Host the privacy policy on a stable URL and add the same link inside the app, in settings.
• Rewrite each usage description in plain language: “We use your camera so you can scan receipts and attach them to an expense.”
• Never request a permission before the user reaches the feature that needs it. Pre-permission prompts on the splash screen get rejected.
• Do not force account creation for features that do not need an account. Browsing, viewing content, and basic utility features must work without sign-up.

What to resubmit: metadata if only the URL was wrong, a new binary if you changed purpose strings or permission timing.

5. Privacy label mismatches and the privacy manifest

This one has quietly become a top rejection driver, and it is the hardest to self diagnose. Apple compares the App Privacy answers you filled in App Store Connect against what your binary actually does, including what your third party SDKs do. If your analytics SDK collects device identifiers and your label says “Data Not Collected”, you get rejected.

Add to that the privacy manifest requirement: third party SDKs on Apple’s list must ship a privacy manifest and signature, and your app must declare approved reasons for using certain APIs (file timestamps, user defaults, disk space, active keyboards, system boot time).

The fix:

• Audit every SDK in your project and list what each one collects. Attribution, crash reporting, ads, chat widgets and A/B testing tools are the usual culprits.
• Update every SDK to its current version so it includes a privacy manifest.
• Add your own PrivacyInfo.xcprivacy file with the required reason API declarations.
• Re-answer the App Privacy questionnaire line by line against that audit, including whether data is linked to identity and used for tracking.
• If you track users across apps, you must show the App Tracking Transparency prompt. No prompt plus tracking equals a 5.1.2 rejection.

What to resubmit: metadata if only the labels were wrong, a new binary if you added or updated the manifest.

6. Guideline 4.2 Minimum Functionality: “your app is too simple”

Apple rejects apps that are essentially a website in a shell, a repackaged PDF, a single static form, or a marketing brochure. The bar is simple: does your app do something a mobile browser cannot do as well?

The fix:

• Add native capabilities that justify the download: offline mode, push notifications tied to real events, camera or biometrics, widgets, Live Activities, Shortcuts or Siri integration, Apple Watch support.
• Remove visible browser chrome. If a webview shows a URL bar or back arrows, it reads as a wrapper.
• If you are a service business, build real account functionality (bookings, history, documents) rather than a link list.
• If your app is genuinely a companion to a business, consider whether it belongs on the store at all or whether a web app plus a native companion makes more sense.

What to resubmit: a new binary. This one almost never gets resolved by argument alone.

7. Guidelines 3.1.1 and 3.1.2: In-app purchase and subscription problems

Monetization rejections are expensive because they often require both code and metadata changes. Frequent causes:

• Unlocking digital features with a payment method other than in-app purchase.
• Links or buttons pointing users to an external website to subscribe, outside of the specific entitlements Apple allows in certain regions.
• Missing subscription disclosures: title, length, price per period, what the subscription includes.
• No functional Restore Purchases button.
• Links to Terms of Use (EULA) and Privacy Policy missing from the paywall and from the App Store listing.
• IAP products still in “Developer Action Needed” or not submitted with the build.
• Promotional images for IAP that duplicate the app icon.

The fix: rebuild the paywall so that price, period, auto-renewal language, restore, terms and privacy are all visible on the same screen without scrolling tricks. Submit IAP products alongside the binary. Make sure your sandbox purchases complete end to end.

What to resubmit: usually a new binary plus corrected IAP metadata.

8. Guideline 5.1.1(v): No in-app account deletion

If your app lets users create an account, it must let them delete it from inside the app. An email link to support is not acceptable. Neither is a “deactivate” option that only hides the profile.

The fix:

• Put a clearly labelled Delete Account entry in settings, reachable in a few taps.
• The flow must initiate full account and data deletion, not just a logout.
• If a regulated industry requires you to retain some records, explain that in the confirmation screen and in your Resolution Center reply.
• If deletion needs a cooling off period, state the timeline in the app.

What to resubmit: a new binary, and point the reviewer to the exact path: Profile, Settings, Account, Delete Account. A longer analysis is available for anyone who wants it.

9. Guideline 4.8: Login services and Sign in with Apple

If you offer a third party or social login as the only or primary way in, you must also offer an equivalent privacy-focused login option. In practice, most teams add Sign in with Apple. Reviewers also check that the alternative is presented with equal prominence, not buried below the fold.

The fix: add a compliant login option that limits data collection to name and email, allows email relay, and does not share data with third parties without consent. Place it at the same visual level as Google or Facebook sign-in.

What to resubmit: a new binary.

10. Guideline 1.2: User generated content without safety tools

Any app where users can post, comment, message, or upload needs a full safety kit. Missing even one item triggers rejection.

• A content filter for objectionable material.
• A mechanism to report offensive content, visible on every piece of content.
• The ability to block abusive users.
• Published contact information so users can reach you.
• An agreement (EULA) that states there is zero tolerance for objectionable content or abusive users, accepted at sign-up.
• A documented commitment to act on reports within 24 hours, including removing content and ejecting the offending user.

What to resubmit: a new binary, with a short description of your moderation process in the review notes.

11. Guideline 4.3: Spam, duplicates and “we already have this app”

This hits template-based agencies, white label products, and portfolios of near-identical apps hardest. Apple also applies it to apps in oversaturated categories that bring nothing new (basic flashlights, wallpaper dumps, generic AI chat wrappers).

The fix:

• If you ship client apps from one template, publish each one on the client’s own developer account, not yours.
• Differentiate the content, branding, feature set and metadata substantially.
• Consolidate variants into a single app with configuration rather than ten near-clones.
• In your reply, explain who the audience is and what is genuinely unique. 4.3 appeals succeed more often than people think when the differentiation is real.

What to resubmit: depends. Sometimes a metadata overhaul is enough, often it needs a product decision.

12. Regional and legal compliance gaps

This bucket grows every year and catches teams who have not touched App Store Connect in a while.

• Trader status in the EU: apps distributed on EU storefronts must declare trader status and display verified contact details. Incomplete declarations block distribution in Europe.
• Guideline 2.3.10: no references to other platforms. Remove “Also on Android” and Google Play badges from screenshots and descriptions.
• Age rating accuracy: the questionnaire must reflect real content, including user generated content, gambling-style mechanics, and unrestricted web access.
• Export compliance and encryption declarations: answer honestly, and add the ITSAppUsesNonExemptEncryption key to avoid the question on every upload.
• Regulated categories: finance, health, dating, cannabis, gambling and pharma apps need documentation proving who you are and that you are licensed. Submit it proactively in the review notes.
• Current SDK requirement: Apple enforces a minimum SDK each year. Check the current requirement in App Store Connect before you build, because uploads with an outdated SDK are rejected at the upload stage.

Honorable mentions worth checking before you submit

• Guideline 2.5.1: use of private APIs or undocumented frameworks.
• Guideline 2.5.2: downloading executable code or changing core functionality after review.
• Guideline 5.1.5: background location without clear justification and a visible benefit.
• Guideline 5.2: using trademarks, logos or content you do not own. Expect to be asked for written permission.
• Guideline 1.4.1: health or medical claims without supporting documentation.
• Guideline 4.7: mini apps, mini games and embedded third party content, which carry extra moderation requirements.

How to reply in Resolution Center so you do not loop

The Reddit threads at the top of search results all say the same thing: teams get rejected repeatedly for the same issue because their reply does not give the reviewer what they need. A good reply is short, factual, and removes all ambiguity.

Use this structure:

1. Acknowledge the specific guideline. “Regarding Guideline 2.1, the sign-in failure you encountered.”
2. State the root cause in one sentence. “Our SMS provider was rate limiting requests from outside the US.”
3. State the fix and the build number. “Fixed in build 142, now uploaded.”
4. Give exact reproduction steps. “Open the app, tap Continue with Email, use review@yourdomain.com / Review2026!, the OTP is permanently 000000 for this account.”
5. Attach proof. A 20 second screen recording of the flow working removes a whole round trip.
6. Ask one precise question if you are stuck. “Could you confirm which device and iOS version reproduced the crash?”

If you genuinely believe the rejection is a mistake, use the App Review Board appeal rather than arguing in Resolution Center. If a rejection is blocking a critical fix or a launch tied to a contractual date, request an expedited review, but keep those requests rare so they stay credible.

Pre-submission checklist

Area	Check before you hit Submit
Build	Tested via TestFlight on iPhone and iPad, latest iOS, production backend, no placeholders
Demo account	Permanent, populated with data, 2FA bypass documented, tested the same day
Review notes	Step by step walkthrough, hidden features explained, video attached if complex
Metadata	Screenshots from this build, no other platforms mentioned, support URL live
Privacy	Policy URL public, labels match SDK audit, privacy manifest present, ATT prompt if tracking
Account	In-app account deletion present, compliant login alternative offered
Monetization	IAP submitted with build, paywall discloses price and terms, restore works
Safety	Report, block, filter and EULA in place if the app has user content
Compliance	Age rating accurate, export compliance answered, EU trader status complete

FAQ

Why is my app being rejected by Apple?

In the large majority of cases it is one of four things: the reviewer could not sign in or could not use the app (Guideline 2.1), your store listing does not match the build (2.3), your privacy policy or privacy labels are incomplete or inaccurate (5.1.1), or the app does not offer enough native functionality (4.2). Read the guideline number in the message, then apply the matching fix above.

How hard is it to get an app approved for the App Store?

It is not hard for a complete, well documented app, but a large share of submissions get rejected at least once. Most reviews are decided within 24 to 48 hours. The teams that get approved on the first attempt are the ones that treat the review notes and demo account as part of the deliverable, not an afterthought.

How many times can I resubmit after a rejection?

There is no hard limit, and repeated rejections do not blacklist your account. What does hurt is submitting the same build with the same problem, because it signals you did not read the feedback. Fix the root cause, explain the change, and attach proof.

Does a rejection delay my whole release?

Only the version under review. Your currently live version stays on the store. Plan for at least one extra review cycle in your release schedule, and avoid submitting on a Friday if you need a fast turnaround.

What is a metadata rejection?

It means the binary passed but something in App Store Connect did not: screenshots, description, demo credentials, privacy policy URL, age rating or privacy labels. You fix it directly in App Store Connect and reply in Resolution Center. No new build is required, which makes it the fastest rejection type to clear.

Can I appeal an App Store rejection?

Yes. If you believe the guideline was misapplied, submit an appeal to the App Review Board with a clear, factual explanation and supporting evidence. Appeals work best for subjective rejections such as 4.3 spam or 4.2 minimum functionality, and poorly for objective ones such as a crash or a missing account deletion flow.

How long does App Store review take in 2026?

Most submissions receive a decision within 24 hours, and the vast majority within 48 hours. Complex apps, regulated categories and first submissions from a new developer account can take longer. Expedited review is available for urgent fixes but should be used sparingly. A comparable breakdown sits on apple.com.

Ship it once, not five times

Nearly every rejection on this list is preventable in under a day of preparation. Build the reviewer account properly, audit your SDKs against your privacy labels, make sure the paywall and the account deletion flow exist, and write review notes that read like a guided tour. Do that and App Review becomes a 24 hour formality instead of a three week negotiation.

If you want a second pair of eyes before you submit, the team at VRS App runs pre-submission audits against the current App Store Review Guidelines and handles resubmissions for teams stuck in a rejection loop. Get in touch and send us your build.