If Apple rejected your vibe-coded app, start with the guideline number and the exact feature named in App Store Connect. AI-assisted development is not itself a rejection category. Guideline 2.1 covers incomplete or broken submissions, 4.2 covers minimum functionality, 4.2.6 covers some apps created through commercial template or app-generation services, 4.3 covers spam and near-duplicate apps, 5.1 covers privacy, and 2.5.2 restricts downloading or executing code that changes app functionality after review.
Fix the cited behavior, show the reviewer how to reproduce the corrected path, and resubmit. Appeal when you can explain why the guideline was applied to the wrong behavior or why the submitted build already complies.
Jump to the guideline on your rejection line:
- Rejected under Guideline 2.1, App Completeness
- Rejected under Guideline 4.2, Minimum Functionality
- Rejected under Guideline 4.2.6, template or app-generation service
- Rejected under Guideline 4.3, Spam
- Rejected under Guideline 5.1, Privacy
- Rejected under Guideline 2.5.2, Software Requirements
What Apple actually changed in 2026
Apple is not banning apps for being built with AI. Four dated facts cover what did change.
December 2025 to April 2026: enforcement of Guideline 2.5.2 against app-building apps. Reporting in March 2026 says Apple blocked an update to the app Anything in December 2025, began removing vibe-coding apps on March 18, 2026, and pulled Anything on March 26, 2026, before it returned by April 3. Replit and Vibecode appear in the same reporting. The cited rule is the one about executing code after review, not the tool used to write the app.
June 9, 2026: the guidelines got stricter on low-quality apps. Apple reworded Guideline 4.3(b) to say “Don’t submit apps that are indistinguishable from what’s already widely available,” and added that it may remove such apps going forward if they are not updated, improved, or do not attract customers. The same update sharpened 1.2 on removing user-generated content that breaks your own terms, and added 4.5.3, which bars using Live Activities for spam, phishing, or unsolicited messaging.
April 28, 2026: a new build floor. Apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26. An old toolchain fails before a reviewer opens a screen.
Unchanged: no guideline names AI-assisted development. The guidelines judge the submitted app and its behavior. That is why a rejection note is worth reading literally rather than as a verdict on how you built it.
Match the rejection note to the fix
| The rejection line Apple sent | What to inspect, and what to change first |
|---|---|
| Guideline 2.1 - Performance - App Completeness | Crashes, broken links, placeholder content, unavailable backends, incomplete purchases, and missing demo credentials or review instructions. Change first: re-run the reviewer’s exact path on a release build and attach the crash log or network trace. |
| Guideline 4.2 - Design - Minimum Functionality | A thin web wrapper, a collection of links, or an app that provides too little lasting utility in its submitted form. Change first: make the one job the listing promises complete inside the app. |
| Guideline 4.2.6 - Design - Minimum Functionality | A service submitted the app for its client, the content provider is not the submitting entity, or the result lacks the customization and unique experience Apple expects. Change first: move the submission to the account of the business whose content the app carries. |
| Guideline 4.3(a) - Design - Spam | Multiple Bundle IDs of the same app, a stack of near-duplicate builds from one account, or code that closely resembles an app already on the store. Change first: consolidate the near-duplicates into one app and document what makes this build different. |
| Guideline 4.3(b) - Design - Spam | An app that is indistinguishable from what is already widely available in an established category. Change first: name the meaningfully different or improved experience, in the app and in the review notes. |
| Guideline 3.1.1 - Business - Payments - In-App Purchase | Unlocking features, subscriptions, in-game currency, premium content, or a full version through your own mechanism instead of in-app purchase. Apple names license keys, QR codes, augmented reality markers, and cryptocurrency wallets as examples. Change first: move every digital unlock to an in-app purchase product, and give restorable purchases a working restore path. |
| Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage | Missing privacy details, vague permission purpose strings, undeclared collection or sharing, and missing permission for third-party data sharing. Change first: rewrite each purpose string to name the feature and the user action, then re-check the App Privacy answers against real network traffic. |
| Guideline 5.1.2 - Legal - Privacy - Data Use and Sharing | Tracking a user across apps and websites you do not own, or handing an advertising or analytics partner that data, without the App Tracking Transparency prompt. Apple also bars withholding content, features, or rewards until the user turns tracking on. Change first: request permission through the App Tracking Transparency API before any tracking call fires, and match the App Privacy answers to what the installed SDKs actually send. |
| Guideline 2.5.2 - Performance - Software Requirements | Code downloaded or executed after review that introduces or changes features, including a builder that runs newly generated apps inside its iOS app. Change first: remove runtime execution of post-review code and describe the remaining architecture exactly. |
Apple’s note should identify a guideline and usually points to a screen, flow, or observed behavior. Diagnose that evidence before rebuilding unrelated parts of the app.
Every line above maps to a numbered rule in Apple’s app guidelines. As of August 2026 there is one App Review Guidelines document rather than a separate set of iOS app guidelines, and no section of it names AI-assisted development, so the number Apple cites is the diagnosis and the common App Store rejection reasons are simply the guideline families that number sits in.
Two of those rows carry more work than one line holds. Digital unlocks have to run through in-app purchase before 3.1.1 is satisfied, which is a build step of its own in an app generated by a tool like Base44, where subscription screens are usually mocked long before StoreKit is wired. And most of what the privacy and completeness rows describe is cheaper to catch on a pre-submission checklist for an AI-built app than in a rejection note a week later.
Guideline 2.1: the submitted path is incomplete
Apple’s current App Review Guidelines require final metadata, working URLs, on-device testing, and demo account information when login is required. Apple’s review-preparation guidance says more than 40% of unresolved review issues are associated with 2.1 App Completeness.
Reproduce the review path on a release build, on a supported device and network. Test account creation or the supplied demo account, the core action shown in the listing, purchases and subscriptions, account deletion where applicable, support and privacy links, and any backend feature that depends on seeded data.
Some rejections have nothing to do with your app logic at all. The build-level causes are the outdated SDK covered above (Xcode 26 and the 26-series SDKs since April 28, 2026), missing support for a required device family or orientation, and unsupported architectures. The related rule to know is Guideline 2.4.2, which says apps should not rapidly drain battery, generate excessive heat, or run unrelated background processes. That is a live risk in generated code, which tends to ship polling loops and timers nobody bounded.
The AxonBuild corpus shows why this deserves a real failure-path test. In a fixed June and July 2026 cohort, 17 of 21 third-party apps recorded errors nowhere a person would see them. That statistic does not measure App Store rejections. It identifies a readiness gap that can leave a reviewer with a spinner, a false success message, or a broken workflow and leave the developer with no useful trace. Silent failures that still return success explains how to find that code path.
I found the same shape directly in a Q&A platform I audited. A wrapper “safe operation” helper swallowed every database error while the UI kept reporting success, and a voting feature answered every click with a fake “Saved offline, will sync” toast with no sync engine behind it to do the syncing. A reviewer clicking that same button during App Review sees precisely the lie your users do, a completed action that never happened. Guideline 2.1 exists to catch exactly that.
Guideline 4.2: the app does not provide enough app-like utility
Guideline 4.2 says an app should provide features, content, and interface beyond a repackaged website. Guideline 4.2.2 specifically addresses apps that are primarily marketing material, web clippings, content aggregators, or collections of links.
Do not answer a 4.2 rejection by adding decorative screens. Identify the job users came to perform and make that workflow complete in the app. If the submitted product is intentionally a website wrapper and adds no useful mobile behavior, distributing it as a web app may fit better than adding filler solely for review.
The corpus’s own version of this failure is compliance theater: fabricated data and marketed workflows that never actually run. One app I audited shipped fake race-winner results and timezone-blind timestamps that showed the wrong time; another marketed compliance checks that were pure decoration. Nothing in that shape survives a reviewer poking at the one feature the listing promises.
Your review notes should state what the app does, where the reviewer can find the core workflow, and any setup needed to reach it. Screenshots and description must match the submitted build.
Guideline 4.2.6: who submitted the app matters
Guideline 4.2.6 is a separate submission-ownership rule for commercialized templates and app-generation services. Apple says an app created through such a service should be submitted directly by the provider of the app’s content. In practice, the restaurant, clinic, creator, or business whose content and service the app represents should control the submission rather than a template vendor submitting many client apps from its own developer account. Apple also tells these services to let clients create customized, innovative apps with unique customer experiences.
Using a commercial AI builder does not automatically fail 4.2.6. Check who owns the content, which entity submitted the app, and whether the finished experience is genuinely customized. If Apple cited 4.2.6, address those three facts directly in the response instead of treating it as a crash or dynamic-code issue.
Guideline 4.3: spam, clones, and too many apps of this type
The line reads “Guideline 4.3(a) - Design - Spam” or “Guideline 4.3(b) - Design - Spam”, and the message often says there are already too many apps of this type on the App Store. An AI-built app can encounter 4.3 when repeated scaffold, content, or interaction patterns make the result look indistinguishable from existing apps. Do not infer priority from the builder label; use the exact rule Apple cited and the submitted app’s behavior.
4.3(a) is about duplication you control. Apple’s text says not to create multiple Bundle IDs of the same app, and gives the example of submitting a separate map app for every city instead of one worldwide map that lets users search any city. If you have shipped a stack of near-identical builds, or your generated app reuses another app’s structure closely enough to read as a copy, that is the 4.3(a) shape. Apple’s own suggestion is to submit a single app and provide the variations through in-app purchase.
4.3(b) is about duplication relative to the store. Apple reworded it on June 9, 2026: do not submit apps that are indistinguishable from what is already widely available. The text names established categories, including dating, flashlight, sound effects, wallpaper, simple timers, and fortune telling, and says new submissions in them are not accepted unless they offer a meaningfully different or improved experience. Apple adds that it may remove apps in those categories going forward if they are not updated, improved, or do not attract customers.
The AI-builder version of this is structural, not cosmetic. The same template scaffold, the same onboarding screens, the same empty states, the same copy patterns, and the same backend layout show up across many generated apps, so a reviewer comparing your binary to the last twenty like it sees a variant rather than a product. Re-prompting for a different color scheme does not change what the reviewer is looking at.
Answering a 4.3 rejection means showing difference, not arguing about it. Name the specific job your app does that the widely available ones do not, point the reviewer at the screen where that shows up, delete the generated screens you never finished, and consolidate sibling builds into one app. If you shipped variants for different cities, teams, or clients, fold them together and use in-app purchase or an in-app selector for the variation.
Guideline 5.1: the privacy behavior or explanation is incomplete
Privacy rejections can involve both the app’s behavior and its disclosures. Permission purpose strings must explain why a protected resource is needed in the context of the feature. Apple’s protected-resource guidance says App Review rejects apps that access protected resources without the required purpose string.
The sub-number to know for AI features is Guideline 5.1.2(i), which appears on rejection lines as “Guideline 5.1.2 - Legal - Privacy - Data Use and Sharing”. It says you must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so. If your app sends a prompt, a photo, a recording, or a transcript to a model provider you do not control, that is third-party sharing and it needs the disclosure and the consent before the first request. Check the full path of prompts, uploads, recordings, contacts, photos, and identifiers. The privacy policy, App Privacy answers, in-app explanation, consent flow, and actual network behavior should agree.
Avoid a generic string such as “camera access is required.” Name the feature and the user action, such as scanning a receipt into an expense record. Request permission when the user starts that feature, not at launch without context.
Guideline 2.5.2: the app changes functionality after review
Guideline 2.5.2 says apps may not download, install, or execute code that introduces or changes app features or functionality, including other apps. This is a runtime rule. It does not make code generated before submission ineligible merely because an AI tool wrote it.
The distinction matters for app-building products. A fixed booking app whose reviewed binary contains its behavior is different from an iOS builder that generates a new mini-app and executes it inside the submitted app. The same March 2026 reporting connected 2.5.2 enforcement to app-building products including Replit, Vibecode, and Anything. That enforcement history helps explain the rule, but it does not guarantee that one architectural workaround will pass a future review.
Apple’s dynamic-code crackdown named three apps. A quality rejection never makes the news, and it’s the one an ordinary vibe-coded app is actually exposed to.
If your rejection cites 2.5.2, map the behavior precisely:
- What code or executable content arrives after review?
- Where does it execute?
- Can it introduce or change features?
- Is the behavior covered by another explicit guideline allowance?
- What changed in the resubmitted build?
Serving HTML5 or JavaScript software that is not embedded in the binary may bring Guideline 4.7 into the analysis, but it is not an automatic safe harbor. That guideline separately governs mini apps, mini games, streaming games, chatbots, plug-ins, and other software that is not embedded in the binary. Limiting output to non-executable content or removing runtime generation may change the 2.5.2 analysis. Apple still decides whether the submitted implementation complies, so describe the architecture accurately instead of presenting any workaround as pre-approved.
The resubmission package
- 01 Copy the guideline number, Apple’s observed behavior, device details, and reviewer steps into your issue tracker.
- 02 Reproduce the cited path on the submitted release build. Save the crash report, screen recording, server trace, or network evidence that identifies the failure.
- 03 Make the narrow fix and test the complete flow, including login, denied permissions, empty data, offline or failed requests, and purchases where relevant.
- 04 Update screenshots, privacy answers, purpose strings, demo credentials, and review notes when the behavior or explanation changed.
- 05 In App Store Connect, reply with the build number, exact navigation steps, expected result, and a concise statement of what changed.
- 06 Resubmit the corrected item. Appeal only when the evidence supports a disagreement with the review outcome rather than a request to overlook an unfixed issue.
Learn the three words App Store Connect uses, because they decide how much work the fix is. Metadata Rejected means App Review did not accept your metadata: you edit the listing, screenshots, review notes, or demo account, then reply, with no new build required. A plain Rejected status means the submission itself was not accepted, which usually means a code change and a new upload. Developers call that second case a binary rejection; the console just says Rejected. Both replies happen in Resolution Center, the thread in App Store Connect where App Review’s message lives and where you click Reply to App Review. The App Review Board is the separate appeal path: Apple asks for specific reasons why the app complies, allows one appeal per submission that did not pass, and expects you to answer any outstanding request for information first.
Apple directs developers with unresolved issues to communicate with App Review in App Store Connect. Its App Review page currently says 90% of submissions are reviewed in less than 24 hours on average, while incomplete submissions can take longer or fail review. That is a platform-wide statistic, not a deadline for your resubmission. Apple publishes no separate turnaround for a corrected build, and expedited review is scoped to a critical bug fix in a shipped version or a time-sensitive event, not to a rejection you would rather not wait out.
Repeat behavior escalates. Apple’s own 4.3(b) text says repeated submissions of low-quality apps may lead to removal from the Apple Developer Program, and its data-sharing rule carries the same consequence for apps that share user data without consent. The ladder runs from one rejection, to removal of the app from sale, to loss of the account. That is the argument for diagnosing the cited guideline before pushing another build at it.
Common questions about App Store rejection
Why would an app get rejected from the App Store?
Because the submission did not meet a specific guideline, and Apple names that guideline number in App Store Connect. The families behind most rejections are app completeness (2.1: crashes, broken links, placeholder content, missing demo credentials), minimum functionality (4.2), spam and near-duplicates (4.3), privacy and tracking (5.1), payments taken outside in-app purchase (3.1.1), and code that changes the app after review (2.5.2). Apple’s own review page says that on average, over 40% of unresolved issues are related to guideline 2.1 alone. How the app was written is not a category; what the submitted build does is.
How often does Apple reject a first submission?
Apple publishes no rejection rate for first submissions specifically, but it does publish the yearly totals. Its 2025 App Store Transparency Report records 9,100,620 app submissions reviewed and 2,093,244 rejected, which is about 23% of everything reviewed that year, with 387,087 approved after a rejection. Apple’s May 2026 newsroom post splits the same figure into more than 1.2 million new apps and nearly 800,000 updates, so new apps account for the larger share. Read 23% as the population rate across every developer and category rather than as odds for your build, and note that the same report puts Performance rejections (1,354,418) well ahead of Design (415,532) and Legal (495,673).
Was my app rejected because I used AI to build it?
Apple’s guidelines assess the submitted app and its behavior. They do not list AI-assisted development as a rejection reason. A generated app can still violate completeness, privacy, functionality, payment, safety, or software requirements, just like manually written software.
Are vibe-coded apps a security risk?
Not because of the tool. Any poorly written app can leak data or expose an endpoint, and AI-generated code raises the odds mainly because it ships defaults nobody reviewed: permissive database rules, keys left in the client bundle, and error paths that swallow failures. App Review is not a security audit either, so passing review is not evidence that your data handling is safe.
Why was my app flagged as spam under Guideline 4.3?
Apple cites 4.3 when your submission looks like a duplicate, either of your own other builds under 4.3(a) or of apps already widely available under 4.3(b), which is the rejection that says there are too many apps of this type on the App Store. Generated apps hit this because one builder produces the same scaffold, screens, and copy patterns for every prompt. Fix it by consolidating near-duplicate builds into one app and naming the meaningfully different or improved experience yours offers, both in the app and in the review notes.
Can I resubmit a rejected app?
Yes. Fix the cited issue, provide current review instructions and credentials, and submit the corrected build or metadata through App Store Connect. If you believe the build already complies, reply with reproducible evidence or use Apple’s appeal process.
What is the difference between Metadata Rejected and Binary Rejected?
Metadata Rejected means App Review did not accept your listing information, so you edit the metadata (description, screenshots, review notes, demo account) and reply in Resolution Center with no new build. A plain Rejected status means the submitted build itself was not accepted, which normally needs a code change and a new upload. “Binary rejected” is the developer shorthand for that second case; App Store Connect shows Rejected for that case, and Invalid Binary when the build itself fails the current requirements.
Apple rejected the binary, not the app. What now?
Read the status, because App Store Connect uses two different ones here and they mean different work. Invalid Binary means the build does not meet the current binary requirements, so App Review has not judged your app at all and you upload a new build that does meet them, most often after a toolchain or SDK problem like the Xcode 26 floor above. A plain Rejected status means App Review looked at the submitted build and did not accept it, which needs the cited guideline fixed in code, a new build uploaded, and a reply in Resolution Center saying what changed. Neither status is called “binary rejected”: that is developer shorthand, and matching it to the status on screen tells you whether the next step is a rebuild or a rewrite of the behavior Apple named.
How long does a resubmission take after a rejection?
Apple does not publish a turnaround specific to resubmissions. Its App Review page says 90% of submissions are reviewed in less than 24 hours on average, and that platform-wide figure is the best available expectation for a corrected build. A metadata-only fix answered in Resolution Center does not require a new binary, but Apple publishes no comparative turnaround that establishes it will move sooner. Expedited review is reserved for critical bug fixes and time-sensitive events rather than rejections.
Should I appeal or fix and resubmit?
Fix and resubmit when you can reproduce the cited problem. Appeal when the guideline appears to have been applied to behavior the app does not perform, or when the submitted evidence supports a different interpretation. An appeal is weaker when the original issue remains visible.
Does Guideline 2.5.2 apply to every vibe-coded app?
No. It concerns post-review code that changes functionality. An app generated before submission and shipped as a fixed reviewed build does not violate 2.5.2 merely because of the tool used to create it. Other guidelines can still apply to the finished app.
Does this App Store rejection also affect Google Play?
Apple’s guideline number has no direct effect on Google Play. Google applies its own Developer Program Policies, including separate rules for broken or limited functionality, repetitive content, web views, user data, and apps that generate AI content. Diagnose a Google Play decision from the policy named in Play Console rather than copying an App Store response. Google’s current functionality and user-experience policy is the closest parallel for crashes and apps with too little useful functionality. Google Play rejection reasons are their own list with their own names and their own remedies, and they are worth reading on their own terms before you reply in Play Console.
What should I test before the next submission?
Test the release build on-device, supply a working review account or approved demo mode, make the backend available, finish purchases and placeholder content, verify support and privacy links, check every permission prompt, and exercise the core workflow under success and failure conditions. The TestFlight submission guide for vibe-coded apps covers the build, upload, tester-group, and beta-review path before another App Store submission. The launch-readiness questions for an AI-built app cover the production side of the same launch.
When every fix and release still depends on you
AxonBuild can trace the failure, repair the broken workflow, and ship the next change without rebuilding the parts that already work.
