App Store Rejection Reasons in 2026 and How to Fix Each One

Most App Store rejections come from incomplete or broken submissions, not from rules about content. Apple's App Review page says over 40% of unresolved issues relate to guideline 2.1, App Completeness, which covers crashes, placeholder content and incomplete information. In Apple's 2025 Transparency Report, the Performance section of the guidelines, where 2.1 sits, was cited in 1,354,418 rejections, more than the other four sections combined.

After completeness, the common App Store rejection reasons fall into four groups. Legal covers privacy policies, permission prompts, account deletion and intellectual property. Design covers spam, copycats and apps with too little functionality. Business covers in app purchase and subscription rules. Safety covers objectionable and user generated content. Each group maps to numbered sections of the App Review Guidelines, and every rejection message names the guideline it relies on.

This page is organized around those guideline numbers, because that is what you will see in the rejection: "Guideline 2.1 Performance: App Completeness", "Guideline 4.3(a) Design: Spam", "Guideline 5.1.1(v) Data Collection and Storage". For each one you get Apple's wording, the usual causes, and a fix. Apple's guidelines were last updated on October 16, 2026, and everything below was checked against the App Review Guidelines and Apple's help pages on October 19, 2026.

A rejection is rarely the end. Apple approved 387,087 submissions after an earlier rejection in 2025, and most of the rest were fixed and resubmitted under a new review. The difference between losing a day and losing two weeks is usually how you respond, which the second half of this page covers: reading the message, replying, resubmitting, using a Bug Fix Submission, and appealing to the App Review Board.

Guideline 2.1(a) asks that every submission be a final version with all necessary metadata and working URLs, with placeholder text, empty websites and other temporary content removed. It asks you to test on device for bugs and stability, and to include demo account details and turn on your backend service if the app has a login. It ends with the rule that causes most rejections: Apple will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems. The full text is in the App Review Guidelines.

The causes are usually ordinary. A crash on a device or iOS version you did not test. A login that fails because the demo account expired or needs a two factor code nobody wrote down. A server that was down when the reviewer opened the app. A support link that points at a page that no longer exists. A feature that says coming soon. None of them are about whether Apple likes the app.

Guideline 2.1(b) covers in app purchases: they must be complete, visible to the reviewer and working, and if a configured product cannot be found or reviewed in the app, you must explain why in the review notes. A frequent version of this rejection comes from the first purchase. Apple's help on submitting in app purchases says your first in app purchase or subscription must be submitted together with a new app version; after the first one is approved, later products can go in on their own.

The fix is a complete submission. Apple's page on providing information for a complete review asks for the concept and business model of a new app, what changed in an update and where to find it, the devices and system versions you tested on, the outside services the app depends on, a demo account that still works when the review starts, credentials for each account type, an account with an expired subscription so the reviewer can see the purchase flow, and any one time code in the Notes field. If your login cannot be shared for legal or security reasons, guideline 2.1(a) allows a built in demo mode with Apple's prior approval.

"Guideline 2.1 Information Needed" is not quite a rejection. It means the reviewer could not finish without something from you: a working login, an explanation of a feature, a document, a video of the app working with its hardware, or an answer about where content comes from. The review pauses until you answer.

Reply to the message in App Store Connect. Do not resubmit. Apple's review status help says that when App Review has requested more information and there are no other issues, you can reply directly, and that resubmitting starts a new review after which App Review can no longer reply to your earlier message. Answer exactly what was asked, attach screenshots or a short screen recording if they make it clearer, and update the App Review Information fields so the next reviewer sees the same details.

If the request is for a call because the login needs a code, Apple says calls are typically completed within three to five business days, according to its complete review page. Putting the code or a code free demo account in the Notes field up front avoids that wait entirely.

Section 2.3 covers everything on the product page. Guideline 2.3.1 says all new features and product changes must be described specifically in the Notes for Review (generic descriptions are rejected), and that marketing an app in a misleading way, such as promoting services it does not offer or a false price, is grounds for removal. Guideline 2.3.2 asks that the description, screenshots and previews make clear which items require an extra purchase. Guideline 2.3.12 asks that the What's New text list significant changes; simple bug fixes and performance improvements may use a generic description.

Screenshots are the metadata rejection Apple explains most fully. Its guideline 2.3.3 help page says screenshots should show the app in use, not merely title art, a login page or a splash screen, and that App Review approves a device's set only when more than half of the screenshots show the app in use. With three screenshots, two must show the app; with four, three must. Overlays are allowed as long as they do not crowd out the app or hide its main functionality, and screenshots must match the current interface. Our App Store screenshot sizes guide covers the sizes Apple requires.

Guideline 2.3.7 limits the app name to 30 characters and forbids packing metadata with trademarked terms, popular app names, pricing or irrelevant phrases. Guideline 2.3.8 asks that icons, screenshots and previews suit a 4+ age rating even when the app is rated higher, and reserves phrases like "For Kids" for the Kids Category. Guideline 2.3.10 forbids names, icons or imagery of other mobile platforms in the app or its metadata. The newest rule, 2.3.14, added on October 16, 2026, applies the same standards to the new creative assets used in product page headers and search results: no misleading references to other apps, no unverifiable claims and no specific or discounted prices.

A Metadata Rejected status means only the product page needs work. Apple's statuses list says to read the message, edit the metadata to resolve the issue and reply to App Review. You do not need a new build, and the review usually resumes quickly once you reply.

Guideline 2.5.1 says apps may only use public APIs, must run on the currently shipping operating system, and should phase out deprecated frameworks. Guideline 2.5.2 says apps must be self contained and may not download, install or execute code that introduces or changes features. That rule is why an app that loads new functionality from a server after review gets rejected or removed, and why HTML5 mini apps, chatbots and plug ins are handled separately under guideline 4.7.

Apple added guideline 2.5.19 on October 16, 2026. It forbids hidden, dormant or undocumented features and says that hiding them in the binary, through code obfuscation or other methods, is grounds for removal from the App Store and termination of the developer account. Apple's announcement of the change describes the target as bait and switch: apps that misrepresent their purpose during review and reveal other capabilities after approval. If your app uses remote configuration to turn features on later, every feature the reviewer can reach after launch has to be present and described in the version you submit.

Build requirements also count as software requirements, though they are enforced at upload rather than in review. Since April 28, 2026, apps uploaded to App Store Connect must be built with the iOS 26 SDK or later, per Apple's SDK requirements notice, and from April 2027 the iOS 27 SDK. A build that does not meet the current binary requirements shows the status Invalid Binary and needs a new upload.

Privacy is the second largest group of rejections and the one with the most specific rules. Guideline 5.1.1(i) says every app must link to its privacy policy both in the App Store Connect metadata field and inside the app, somewhere easy to find. The policy must say what data the app collects, how and for what, confirm that any third party receiving the data gives it equal protection, and explain retention, deletion and how a user withdraws consent.

Guideline 5.1.1(ii) requires consent before collecting user or usage data, even data treated as anonymous, and says paid functionality must not depend on granting access to that data. It also requires purpose strings, the sentence iOS shows in each permission prompt, to describe the use clearly and completely. Apple's purpose string help page gives the contrast it is looking for: "To use location." is insufficient; "The app uses location data to determine the recommended route to your destination and provide turn by turn directions." is clear. Write one specific sentence per protected resource, localize it for every language you support, and remove SDK code that requests a permission you do not need.

Guideline 5.1.1(iv) says apps must respect permission settings and not trick or force people into unnecessary access. Apple's example is an app that posts photos to a social network but asks for the microphone first. If someone declines location, offer a way to type an address instead. Guideline 5.1.2(i) adds that you must clearly disclose where personal data is shared with third parties, including with third party AI, and get explicit permission before doing so. An app that sends user text or photos to an outside AI model needs that disclosure and consent in the app, not only in the privacy policy.

Two technical requirements cause privacy rejections at upload. Since May 1, 2024, apps that use APIs on Apple's required reason list must declare an approved reason in a privacy manifest, according to Apple's privacy update for submissions. And when you add an SDK from Apple's list of commonly used third party SDKs, 86 entries including Firebase, Alamofire, Flutter, OneSignal and Lottie, you must use a version that ships its own privacy manifest, signed if it is a binary dependency.

Guideline 4.3 is the rejection developers find hardest to fix, because it is about the idea rather than a bug. It has two parts. Guideline 4.3(a) says not to create multiple bundle IDs of the same app. Apple's example is a separate map app for every city instead of one map that searches any city, and its advice is to submit a single app and offer variants for locations, teams or schools through in app purchase.

Guideline 4.3(b) says not to submit apps that are indistinguishable from what is already widely available. It names categories that are well established on the App Store, including dating, flashlight, sound effects, wallpaper, simple timers and fortune telling, and says Apple will not accept new ones unless they offer a meaningfully different or improved experience. Apps built from commercial templates or app generators that many others also ship fall under the same rule.

Apple revised both parts on June 8, 2026, clarifying the basis for the guideline and adding examples. The reporting collected by Michael Tsai links a surge in submissions in 2025 and 2026 partly to apps built quickly with AI coding tools, and that is the background against which 4.3 is applied today.

What works, in our experience of the cases developers describe: change the app, not the argument. Merge near identical apps into one. Remove template screens and stock assets. Add the feature that makes the app different, then say in the review notes, in two or three plain sentences, what this app does that the obvious alternatives do not. A reply that only insists the app is unique, with no change in the build, rarely moves a 4.3 rejection. If several of your apps were rejected under 4.3(a), take it seriously: repeated spam can lead to removal from the Apple Developer Program.

Guideline 4.2 opens with one sentence that explains most of these rejections: your app should include features, content and interface that elevate it beyond a repackaged website. It continues that if an app is not particularly useful, unique or app like, it does not belong on the App Store. Guideline 4.2.2 adds that, other than catalogs, apps should not primarily be marketing materials, advertisements, web clippings, content aggregators or a collection of links. Guideline 4.2.3 says an app must work on its own without requiring another app, and must disclose the size of any extra download before it starts.

Webview apps are the classic case. Wrapping a website in a native shell is allowed, but an app that shows the same site with no added value usually gets a 4.2 rejection. The same goes for single screen utilities that do one small thing a built in iOS feature already does, and for apps whose content is a book or game guide, which Apple says belong in Apple Books.

The fix is to give the reviewer a reason the app exists. Use device capabilities the website cannot: offline access, widgets, notifications people opt into, the camera, Apple Pay, Sign in with Apple, sharing to other apps, or data that stays on the device. Make the app usable without logging in when you can. Then say in the review notes what the app does that the website does not. These suggestions are our reading of the guideline and of developers' published experience, not a list Apple provides.

Guideline 4.1 asks developers not to copy the latest popular app or make minor changes to another app's name or interface and pass it off as their own. Guideline 4.1(b) treats impersonating other apps or services as a violation of the Developer Code of Conduct, and 4.1(c) forbids using another developer's icon, brand or product name in your icon or name without approval. Apple's copycat help page lists the usual triggers: copied features or look and feel, a name or icon close to an existing app, other brands in the title, subtitle or keywords, screenshots that do not show your real app, and an outdated developer name or support URL. The fix in each case is to make it plainly yours, or to get written permission and attach it.

Guideline 4.8 applies to apps that use a third party or social login, such as Google Sign In, Facebook Login, Sign In with LinkedIn or Log in with X, to set up the user's main account. Those apps must also offer, as an equivalent option, another login service that limits data collection to name and email, lets people keep their email private, and does not collect interactions for advertising without consent. Sign in with Apple meets all three, which is why most developers add it when this rejection arrives, though the guideline describes the features rather than naming one service.

The requirement applies only when a third party or social login sets up the main account, so an app that uses only its own email and password login is outside it. If your app offers Sign in with Apple, remember the account deletion rule: deleting an account must also revoke the Sign in with Apple tokens.

Guideline 3.1.1 says that to unlock features or functionality inside an app, such as subscriptions, game currencies, levels, premium content or a full version, you must use in app purchase, and you may not use your own unlocking mechanisms such as license keys, QR codes or crypto wallets. It is the core of the Business section, which was cited in 283,820 rejections in 2025.

Subscriptions have their own rules. Guideline 3.1.2(a) says an auto renewing subscription must provide ongoing value, last at least seven days and be available across all of the user's devices. Guideline 3.1.2(c) says that before asking someone to subscribe, you should clearly describe what they get for the price, and communicate the requirements in Schedule 2 of the developer agreement. Paywalls that hide the price, the renewal period or what the subscription includes are a common Business rejection.

There are exceptions people often miss. Reader apps under 3.1.3(a), such as magazines, books, music and video services, may let users access content they bought elsewhere. Multiplatform services under 3.1.3(b) may unlock purchases made on other platforms, as long as those items are also offered as in app purchases. And guideline 3.1.1(a) says that in the United States storefront, developers do not need an entitlement to include buttons, external links or other calls to action. Elsewhere, the same guideline describes entitlements developers may apply for to link to a permitted destination for purchases.

Most in app purchase rejections are mechanical rather than about policy: a product the reviewer cannot find, a restore purchases button that does nothing, a purchase that fails in the sandbox, or a first subscription submitted without an app version. Test every product in the sandbox with a fresh account before submitting, and leave the reviewer an account with an expired subscription.

Safety rejections were the smallest group in 2025, cited 151,159 times, but they are strict. Guideline 1.2 says apps with user generated content must include a method for filtering objectionable material, a way to report offensive content with timely responses, the ability to block abusive users, and published contact information. If your app has comments, chat, profiles, uploads or reviews, all four must be in the build the reviewer sees.

Apple has tightened 1.2 twice in 2026. On February 6, 2026 it clarified that apps with random or anonymous chat are subject to the user generated content rules. On October 16, 2026 it added that content moderation now explicitly covers nonconsensual intimate imagery, including imagery made with AI tools, and that developers who fail to put safeguards in place, or do not fix violations after notice, risk removal. Apps that generate or edit images of people with AI should treat moderation as a launch requirement.

The rest of the Safety section covers objectionable content, apps for children in the Kids Category, physical harm, and medical claims. Health apps that diagnose or treat need regulatory clearance for each country where they are available, which belongs in the review notes before you submit.

People now search for "Apple rejected vibe coded app", and the pattern is real even though Apple has no rule about how an app is written. Apps generated quickly with AI coding tools tend to hit the same four guidelines. They resemble many other apps in a crowded category, which is 4.3(b). They wrap a simple idea or a website, which is 4.2. They ship with placeholder screens, untested flows or a backend that is not running, which is 2.1. And they sometimes send user data to an AI model without the disclosure and consent that 5.1.2(i) requires.

The volume behind this is large. The reporting collected by Michael Tsai cites Appfigures data showing App Store submissions up 24% in 2025 through November, and The Information reporting that new apps grew about 30% in 2025. Apple has not tied its rejection decisions to how an app was built, and its newest rule, 2.5.19 against hidden or undocumented features, applies to every app the same way.

If you build with AI tools, treat the submission as the part they do not do for you: test on a device, remove template content, write the privacy policy and the permission prompts, add account deletion if there are accounts, and write review notes in your own words about what makes the app different.

When a submission does not pass, the version status changes to Rejected, or Metadata Rejected if only the product page is the problem, and the submission shows Unresolved Issues. Apple's statuses list says App Review notifies App Store Connect users with the Admin, App Manager or Developer role, and its contact page says the message in App Store Connect details the issues that need your attention, with the guideline and usually a screenshot or steps.

Many developers still call this the Resolution Center. Apple's current help pages call it the App Review section of App Store Connect, and the button you use to answer is Reply to App Review. A specialist familiar with your app replies there. Apple asks you to be specific about the feature, guideline or step you need clarified, and not to use that field to appeal or to ask for an expedited review, which have their own forms.

A rejection does not affect the version already on the App Store. Your live app stays available while you fix the new one. Only the submitted version is held, along with any in app purchases or other items in the same submission. If some items were accepted and others rejected, Apple's guidance is to remove the rejected items and resubmit so the accepted ones can move ahead.

How long all this adds depends on the path you take, covered in the table below and in our guide to how long App Store review takes.

If you believe the app follows the guidelines, you can appeal to the App Review Board. Apple's appeal help page says an appeal is appropriate when an app was rejected or removed but you believe it follows the App Review Guidelines and the developer agreement, when your account faces termination, or when you believe you were treated unfairly. It is not the channel for a status update or an expedited review.

The steps are set. First reply to the rejection in App Store Connect and clarify the issue; appeal only if that does not resolve it. Then use Apple's Submit an appeal form, point to the specific requirements involved and explain how your app satisfies each one. The Board messages you in App Store Connect when its investigation is complete, and may ask for more information or schedule a call. Submit one appeal per rejected app and cover every guideline in that one appeal; the form takes up to five apps at a time. Resubmitting the app closes the appeal.

Apple shows what a good appeal looks like. Its complete example reads, in substance: the app was rejected under 2.1 for incomplete information, the demo account and setup steps are in App Review Information, and screenshots show the feature working. Its incomplete example says only that the app matters to the business and should not have been rejected. Apple adds that a complete appeal helps the Board work quickly but does not guarantee the decision is overturned.

Apple does not publish how many rejection appeals succeed. Its 2025 Transparency Report reports appeals of app removals instead: 26,305 appeals and 423 apps restored, about 1.6% by our division. In the UK, Apple's commitments to the CMA of 30 March 2026 promise an appeal to the App Review Board as a matter of right, an explanation of how each rejected submission breaks the guidelines, and yearly figures for UK developers on appeals from rejections, apps approved after appeal and the share of appeals completed within 60 days, with the first report due by 31 March 2027.

If an update to an app that is already on the App Store is rejected for something with no legal or safety concern, Apple may let you ship it anyway and fix the issue next time. Apple's Bug Fix Submissions page says the offer appears at the top of the rejection message with the line that the issues are eligible to be resolved on your next update.

To accept, reply to the message, say you would like the current submission approved and will address the issues in the next update, and do not resubmit, because that triggers a new review. App Review replies to confirm and approves the submission. In the next update you must resolve every deferred issue, and issues deferred once cannot be deferred again. If the note is not in the message, the submission does not qualify and the issues have to be fixed first.

Google Play reviews against its Developer Program Policies, and its enforcement page lists the outcomes: rejection, removal, suspension, limited visibility or regions, restricted accounts and termination. The rejection message names the policy, and Google emails instructions on how to appeal if you believe it acted in error.

The Google Play rejection that has no App Store equivalent is the Data safety form. Google's Data safety help says every app published on Google Play must complete it, even apps that collect no data, that developers alone are responsible for complete and accurate declarations, and, asked whether an app can be blocked over its Data safety submission, answers "In short, yes." Inaccurate declarations must be fixed, and apps that do not comply can have updates blocked or be removed.

Two more differences matter for planning. New personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers for at least 14 days before applying for production access, per Google's testing requirements. And Google's removal and appeal help allows one appeal per enforcement action, answered in Chinese, English, Japanese or Korean. If you ship on both stores, keep the privacy policy, Apple's privacy answers and Google's Data safety form in sync, because a mismatch is the easiest rejection to cause on either side.

Some of the same rules apply to how you promote the app. Guideline 2.3.1 warns that marketing an app in a misleading way, inside or outside the App Store, such as promoting features it lacks or a false price, is grounds for removal. Apple's separate marketing guidelines govern how you show the App Store badge, Apple devices and your rating in ads and social posts.

Our guide to the App Store marketing guidelines covers those rules in plain words, and the App Store statistics page tracks the yearly rejection and removal numbers as Apple publishes them. For the launch itself, the app launch checklist puts every review step in order.

Getting through App Review is the hard part of shipping an update. Telling people about it should not be. Spreadcast watches your public App Store listing every day, sees each approved version the moment it goes live, and turns it into a designed post with your own icon and screenshots in an iPhone frame, with a caption written for each network. It publishes to Instagram, Facebook, LinkedIn, Pinterest and your other connected accounts on the schedule you set.

The posts follow Apple's marketing rules: real screenshots of the current app, no invented features and no prices that might change. The same daily check turns new 5 star reviews and rating milestones into posts. Paste your App Store link on the start page to see a post drafted from your listing, and see the plans for automatic publishing.