18 Reasons Your App Was Rejected by Apple and How to Fix Each One

An app rejected by Apple always comes with a reason and the rejection message in App Store Connect names the exact guideline the build broke. Start there. That one number tells you whether the fix is a code change, a new build, or a quick edit to your store listing.

Rejections are common. Apple turned down about 1 in 4 of the 9.1 million submissions it reviewed in 2025. Most trace back to Guideline 2.1, App Completeness: crashes, placeholder content, broken links and demo accounts that don’t work.

Plenty of rejections have nothing to do with broken code. A screenshot that no longer matches your app, a vague permission message or a missing privacy manifest entry can stop a release just as easily as a crash. 8 of the 18 reasons in this guide get fixed without changing your app’s logic.

Below, each reason comes with the guideline Apple cites, how to fix it, and the type of mobile app testing that catches it before you submit. After the list, you’ll find how to resubmit a rejected app and what to check before sending it back. Guideline numbers are current as of the App Review Guidelines updated on 16 October 2026.

18 App Store Rejection Reasons by Guideline

The 18 reasons below follow Apple’s 2025 rejection volume, starting with the guideline section that causes the most rejections.

1. The App Crashes or Shows Obvious Bugs (Guideline 2.1)

Guideline 2.1(a) asks for a final, stable build that you’ve tested on a real device. App Review tests the exact build you uploaded, and one crash during that session is enough to send it back.

Fix: Pull the crash report in Xcode, fix the defect, and rerun your regression suite on the release build, not a debug build.

Caught by: functional and regression testing on real devices.

2. Placeholder Content or an Unfinished Build (Guideline 2.1)

Lorem ipsum text, sample products, “coming soon” screens and test accounts all tell the reviewer the app isn’t finished. Guideline 2.1(a) asks for final versions with temporary content removed. Guideline 2.2 sends demos, betas and trial versions to TestFlight, Apple’s channel for beta testing, instead of the App Store.

Fix: Strip out placeholder copy, test assets and dead buttons, and pull any unfinished feature from the release.

Caught by: smoke testing of the release build.

3. The Reviewer Cannot Sign In or Reach Key Features (Guideline 2.1)

The reviewer needs to reach every account-based feature. Guideline 2.1(a) asks for an active demo account or a full demo mode, plus a backend that stays live. Expired credentials, two-factor codes sent to a team phone, region locks and a server outage during review all leave the reviewer stuck at the login screen.

Fix: Add working demo credentials in the App Review Information section, keep your backend running through review, and attach a demo video for features that need special hardware.

Caught by: access testing with the exact demo account.

💡 Review Note: Before every submission, sign in with the demo account on a device outside your team’s network, with no saved session. That’s the same first login the reviewer sees, two-factor prompts and region checks included.

4. Vague Notes for Review (Guideline 2.3.1)

Guideline 2.3.1(a) asks you to describe new features and changes in the Notes for Review field with specificity, and Apple rejects generic notes. “Bug fixes” on a build with new screens leaves the reviewer guessing.

Fix: List each new feature, where to find it, how to reach paid or login-gated areas, and why each permission is requested.

Caught by: a release-readiness review of the submission.

5. Broken Links or a Missing Support URL (Guidelines 2.1 and 1.5)

Guideline 2.1(a) requires every URL to work. Guideline 1.5 requires an easy way to contact you through the app and its Support URL. Apple’s App Review page lists broken links among the most common rejection causes, and every app needs a working support link and a working privacy policy link.

Fix: Open every in-app link and every URL in App Store Connect on the release build, including the support, marketing, privacy policy and terms pages.

Caught by: link validation during functional testing.

6. Screenshots or Metadata That Do Not Match the App (Guideline 2.3)

Guideline 2.3 requires your description, screenshots, previews and privacy details to match the app’s core experience. Guideline 2.3.3 adds that screenshots show the app in use, not just title art, a login page or a splash screen.

A typical slip is a screenshot of a screen the reviewer never reaches on first launch, such as a redesigned home screen or a feature tucked behind onboarding. Promised features that aren’t there, and prices in the app name, break Guidelines 2.3 and 2.3.7 too.

Fix: Capture new screenshots from the submitted build’s first-launch flow, upload them in App Store Connect, and resubmit the same build. No new binary required.

Caught by: checking the store listing against the release build.

7. Hidden or Undocumented Features (Guideline 2.5.19)

Guideline 2.5.19 bans hidden, dormant and undocumented features. Hiding features through code obfuscation is grounds for removal from the App Store and termination of your developer account. Unlisted debug menus and server-controlled features that change what the app does after approval fall under this rule.

Fix: Remove dormant code paths, switch off debug menus in release builds, and document every feature in the Notes for Review.

Caught by: exploratory testing of the release build with server flags set to production.

8. An Inaccurate Age Rating (Guideline 2.3.6)

Guideline 2.3.6 asks for honest answers to the age rating questions in App Store Connect, so parental controls work as expected. Mature user-generated content, gambling-style mechanics and ads that exceed your rating all create a mismatch. Guideline 2.5.18 also requires every ad to suit the app’s age rating.

Fix: Answer the questionnaire based on everything the reviewer can reach, including ads and web views.

Caught by: a content review of every reachable screen.

9. Poor Performance on Supported Devices or Private APIs (Guidelines 2.4 and 2.5)

Guideline 2.4.2 requires apps to use power efficiently, without fast battery drain, excess heat or unnecessary strain on the device. Guideline 2.5.1 limits you to public APIs on the currently shipping OS. Guideline 2.5.5 requires the app to work on IPv6-only networks. Real device testing on physical iPhones and iPads exposes battery drain, heat and memory pressure that a simulator does not reproduce.

Fix: Test across your supported device and OS matrix, remove private and deprecated API calls, and run the app on an IPv6-only network.

Caught by: compatibility and performance testing on real devices.

10. A Privacy Policy, Privacy Label or Privacy Manifest Mismatch (Guideline 5.1.1)

Guideline 5.1.1(i) requires a privacy policy link in App Store Connect and inside the app. The policy lists the data you collect, every use, how third parties protect it, and how long you keep it and delete it. Apple holds you responsible for third-party SDKs too, so an App Privacy label that skips SDK data creates a mismatch.

The privacy manifest is a separate check. A privacy manifest (PrivacyInfo.xcprivacy) is a file in your app bundle that declares an approved reason for each required reason API your app or its SDKs call, such as UserDefaults. Since 1 May 2024, App Store Connect refuses uploads that call these APIs without a declared reason, before App Review even starts. Apple’s email cites issue ITMS-91053, Missing API declaration.

Fix: Map every data type your app and its SDKs collect, align the privacy policy with your App Privacy answers, and declare each required reason API in the privacy manifest.

Caught by: privacy testing with network traffic inspection, plus a manifest audit of every SDK.

11. Vague Permission Purpose Strings (Guideline 5.1.1(ii))

A purpose string is the message iOS shows when your app asks for access, such as location or camera. Guideline 5.1.1(ii) requires that message to explain clearly and completely how the app uses the data. “This app needs your location” names no use. “Used to show stores near you” does. Purpose strings live in your Info.plist file, so the fix takes a new build but no logic change.

Fix: Rewrite each purpose string around its specific use, ask for access at the moment the feature needs it, and keep the app working when the user says no.

Caught by: permission flow testing, including the denied path.

12. No In-App Account Deletion (Guideline 5.1.1(v))

Guideline 5.1.1(v) requires every app that lets people create an account to let them delete it from inside the app. Deactivation doesn’t count. A sign-up flow with no matching deletion path fails review.

Fix: Add a delete-account option in account settings that removes the account record and its data.

Caught by: account lifecycle testing, from sign-up to deletion.

13. A Substandard User Interface (Guideline 4.0)

Guideline 4 sets minimum design standards for apps that are simple, refined, innovative and easy to use. Apple’s App Review page names a substandard interface as a common rejection cause. It points developers to the Human Interface Guidelines, Apple’s design rules for its platforms. Truncated text, broken iPad layouts and unresponsive controls fall short of that bar.

Fix: Review every screen against the Human Interface Guidelines on each supported screen size and in Dark Mode.

Caught by: UI testing and usability testing.

14. A Copycat or Spam App (Guidelines 4.1 and 4.3)

Guideline 4.1 rejects apps that copy another app’s name, interface or concept with small changes, or use another developer’s icon, brand or product name without approval. Guideline 4.3(a) rejects multiple Bundle IDs of the same app.

Guideline 4.3(b) goes further. It rejects apps that look like what’s already widely available, unless yours offers a meaningfully different experience. Apple names dating, flashlight, wallpaper and fortune-telling apps as saturated categories. Guideline 4.2.6 also rejects apps built from a commercial template unless the content provider submits them.

Fix: Merge near-identical apps into 1 app, remove competitor names from your metadata, and build features the category lacks. A 4.3(b) rejection takes its own response, covered after this list.

Caught by: a competitive feature review before development.

15. Minimum Functionality or a Web Wrapper (Guideline 4.2)

Guideline 4.2 requires features, content and UI that lift an app above a repackaged website. Guideline 4.2.2 rejects apps that are mainly marketing material, web clippings, content aggregators or a collection of links.

Fix: Add functionality your mobile website doesn’t offer, such as offline access, native navigation, device integrations and account features.

Caught by: a feature audit against your mobile website.

16. Third-Party Login Without an Equivalent Option (Guideline 4.8)

Guideline 4.8 applies when your app uses a third-party or social login for the user’s main account, such as Google Sign-In or Facebook Login. In that case, the app also offers an equivalent login option that:

• limits data collection to name and email address
• lets users keep their email address private
• doesn’t track app activity for ads without consent

Apps that use only the company’s own account system are exempt. So are education and enterprise apps that require an existing account.

Fix: Add a qualifying option, such as Sign in with Apple, next to every third-party login button.

Caught by: authentication flow testing.

17. In-App Purchase and Subscription Violations (Guidelines 3.1.1, 3.1.2 and 2.1(b))

Guideline 3.1.1 requires in-app purchase for anything that unlocks digital features, subscriptions, in-game currency or premium content. Physical goods and services used outside the app go through other payment methods under Guideline 3.1.3(e). Guideline 3.1.2(c) asks you to state clearly what a subscriber gets for the price. Guideline 2.1(b) requires every in-app purchase to be complete, visible to the reviewer and working.

Fix: Test every purchase, restore and subscription flow in Apple’s sandbox, and explain hard-to-find purchases in the Notes for Review.

Caught by: in-app purchase testing in the sandbox.

18. User-Generated Content Without Moderation (Guideline 1.2)

Any app where users post content, including social and AI content creation apps, needs 4 safeguards under Guideline 1.2:

• a filter for objectionable material
• a way to report content, with timely responses
• the ability to block abusive users
• published contact information

Fix: Build all 4 safeguards before you submit, and describe each one in the Notes for Review.

Caught by: moderation flow testing.

Which App Store Rejections Need No Code Change?

8 of the 18 App Store rejection reasons need no code change, and 5 of those are fixed in App Store Connect with the same build. Check the guideline number first, and you’ll know which kind of fix you’re facing before you open Xcode.

The table sorts every reason by fix type, from a quick metadata edit to a product decision, and shows which test catches it.

¹ Broken URLs in App Store Connect are fixed as metadata, with the same build.
² A missing privacy manifest entry takes a new build.

The other 10 reasons split three ways: 7 need a code change, 2 need a product decision, and in-app purchase issues fall on either side depending on the cause.

💡 Review Note: Purpose strings and the privacy manifest ship inside the app binary, so fixing either one takes a new build even when no logic changes. Screenshots, age ratings, demo credentials and Notes for Review change in App Store Connect, and the same build goes back to App Review.

Which App Store Rejections Can Mobile App Testing Catch?

Testing the release build catches 15 of the 18 rejection reasons. Mobile app testing checks an app’s functionality, compatibility, performance and security on real mobile devices. The other 3 reasons (vague Notes for Review, copycat or spam apps, and minimum functionality) come down to submission content and product scope. A release review or competitive review catches those instead.

Real-device testing of the release build covers 8 of the 9 Performance reasons, and privacy testing covers all 3 Legal ones. Between them, those 2 scopes handle 11 of the 18. Both belong to standard iOS app testing, which combines manual and automated checks on iPhone and iPad builds before release.

How Do You Fix an App Rejected by Apple?

To fix an app rejected by Apple, read the guideline in the rejection message, reproduce the problem on the build Apple tested, fix it, then resubmit or reply to App Review. Here’s the full process in 7 steps.

1. Read the Guideline Number Before Debugging

Open Apps in App Store Connect, select View App Review Issues & Messages, and click Resolve next to the submission. The message lists every guideline the reviewer cited. A citation of 2.3.3 or 5.1.1(ii) points to screenshots or purpose strings, not broken code, so the guideline number tells you whether to start in App Store Connect or in Xcode. While the submission shows Unresolved Issues, you can’t add new items to it.

2. Reproduce the Issue on the Submitted Build

Install the exact build Apple reviewed, on the device type and iOS version named in the rejection. Release builds run with production endpoints and compiler optimisation switched on, so reproduce the issue on the release build, not in debug.

3. Fix, Retest and Resubmit

Fix the defect, rerun the regression suite on everything the change touches, and resubmit. Regression testing confirms that the fix did not break features that passed before.

Metadata rejections don’t need a new build: Apple accepts the same build once the metadata is corrected. You can edit each rejected item once before resubmitting. Apple’s App Review Help states that resubmitting with issues still unresolved only delays review and ends with the same result.

4. Reply to App Review

Use Reply to App Review on the submission page to explain a fix, answer a question, or show that the app already complies. Replies take up to 4,000 characters, plus attachments such as screenshots or a screen recording.

5. Request an App Review Appointment

Book a 30-minute App Review appointment over Webex to talk through the guidelines, common rejection reasons and how your app lines up with them.

6. Accept a Bug Fix Submission Offer

Apps already on the App Store qualify for bug fix submissions. Apple approves the bug fix update and lets you resolve other guideline issues in your next submission, except legal and safety issues.

7. Appeal to the App Review Board

When App Review has misunderstood your app’s concept or treated it unfairly, file an appeal with the App Review Board. Submit 1 appeal per rejected submission, give specific reasons the app complies, and answer any open information requests first.

Apple’s App Review page states that 50% of submissions are typically reviewed in under 24 hours and 90% in under 48 hours. You can track progress in the App Review section of App Store Connect.

How Do You Respond to a Guideline 4.3(b) Spam Rejection?

To respond to a Guideline 4.3(b) spam rejection, change the app’s concept or feature set, then explain the difference to App Review or file an appeal. A new interface on its own leaves the outcome unchanged, because 4.3(b) judges whether your app stands apart from apps already on the store, not how its screens look.

A 4.3(b) rejection message has 4 parts. Here’s what each part of a recent message says, and what it asks you to do.

The Extended Review notice makes resubmitting an unchanged build the riskiest move. Take these 5 steps instead:

• Ask App Review, in a reply in App Store Connect, which features look duplicated.
• List what your app does that competing apps don’t, with screenshots or a screen recording.
• Rework the concept before resubmitting, since interface changes alone leave the 4.3(b) assessment where it was.
• File an appeal with the App Review Board when your app already differs and the reply doesn’t settle it.
• Skip the expedited review form, which Apple reserves for critical bug fixes and event-related releases.

Example: An AI Hairstyle App Rejected Twice Under 4.3(b)

A developer publicly described what happened to an app that adds AI-generated hairstyles to a selfie. The first build was rejected under Guideline 4.3(b). The developer redesigned the interface and resubmitted. The second build was rejected as well, this time with the Extended Review warning about removal from the Apple Developer Program. The same app was already live on Google Play.

The redesign didn’t help, because 4.3(b) looks at the concept, and AI photo filters and hairstyle try-on apps sit in a crowded category. What actually addresses a 4.3(b) rejection is one of 3 responses:

1. a reworked feature set
2. a reply asking App Review which features it sees as duplicated
3. an appeal to the App Review Board

What Percentage of App Submissions Does Apple Reject?

Apple rejects 23–28% of app submissions each year, according to its App Store Transparency Reports. In 2025, Apple also approved 387,087 submissions that had been rejected earlier, so a rejection is a step in the process, not a final verdict.

Here’s how the numbers compare across 3 report years:

The rejection rate dropped 4.5 percentage points between 2022 and 2025. Apple counts every upload as a submission, updates included, so a single app can collect several rejected submissions before it’s approved.

In 2025, Performance guidelines accounted for 1,354,418 rejections. Legal followed with 495,673, then Design (415,532), Business (283,820) and Safety (151,159). One submission can fail more than 1 section, so these totals add up to more than the overall figure.

What Should You Test Before Submitting to App Review?

Test 21 items across 5 stages before you submit: build stability, reviewer access, store listing, privacy, and payments and safety. The list follows the order of a typical release cycle.

Build stability

• Run the full regression suite on the release build.
• Test every supported iPhone and iPad screen size.
• Test on the currently shipping iOS version.
• Monitor battery drain, heat and memory use during extended sessions..
• Test on an IPv6-only network.

Reviewer access

• Verify the demo account signs in without two-factor prompts.
• Keep backend services live for the full review window.
• Write specific Notes for Review for every new feature.
• Remove placeholder text, test data and debug menus.

Store listing

• Retake screenshots from the submitted build’s first-launch flow.
• Match the description to the features in the build.
• Answer the age rating questionnaire against all reachable content.
• Open every support, privacy policy and marketing URL.

Privacy

• Align the privacy policy with the App Privacy answers and SDK data.
• Declare every required reason API, including SDK usage, in the privacy manifest.
• Rewrite each purpose string around its specific data use.
• Test account deletion from inside the app.
• Test the denied path of every permission prompt.

Payments and safety

• Test purchase, restore and subscription flows in the sandbox.
• Add an equivalent login option next to every third-party login.
• Test reporting, blocking and filtering for user-generated content.

Together, the 21 items cover all 18 rejection reasons in this guide. Release testing beyond App Review goes wider because a full mobile app testing checklist adds 12 categories, including accessibility, interrupt and localization testing.

FAQ

How Long Does Apple Take to Review a Resubmitted App?

Apple’s App Review page states that 50% of submissions are typically reviewed in under 24 hours and 90% in under 48 hours. According to the App Review Guidelines, repeated rejections for the same guideline make later reviews take longer.

Does One Rejection Affect Future Submissions?

No. The App Review Guidelines attach no penalty to a single rejection you’ve fixed. Repeated rejections for the same violation, or attempts to game the review process, do extend review times.

Can Apple Remove an App After Approval?

Yes. Apple removed 166,899 apps from the App Store in 2025, according to its App Store Transparency Report. Fraud under the Developer Program License Agreement accounted for 90,608 removals. Guideline 4.0 design issues, from a cleanup of outdated apps, accounted for 72,271.

Does Google Play Approval Lead to App Store Approval?

No. Google Play approval has no bearing on App Review. Apple applies its own App Review Guidelines, and Guideline 4.3(b) compares your app with apps already on the App Store, whatever happened on other stores.

Does TestFlight Review Reject Builds?

Yes. TestFlight App Review checks builds before external beta distribution, and Guideline 2.2 requires TestFlight builds to follow the same App Review Guidelines as App Store submissions.

How Does Testscenario Test Apps Before App Store Submission?

Testscenario tests your iOS release build against all 18 rejection reasons in this guide, on real devices, before it reaches App Review. Our QA engineers run functional, compatibility, privacy and permission testing. They then check your store listing, demo account and Notes for Review against the App Review Guidelines.

An app rejected by Apple costs at least 1 review cycle, and Guideline 2.1 alone accounts for over 40% of unresolved review issues. Testscenario holds a 4.9 rating on Clutch from 17 reviews across 81 client engagements. This pre-submission check is part of Testscenario’s mobile app testing services, and testing starts within 48 hours.