Why Apple rejects AI-built apps, and how to pass review

Apple doesn’t reject an app because it was built with AI: none of its guidelines targets that. It rejects apps that look unfinished, that are just a wrapped website, that look too much like others, or that share data without saying so. Those happen to be the most common flaws of an app generated in one evening.

What the numbers say

In 2025, Apple reviewed 9.1 million submissions and rejected 2.09 million. A submission can be rejected for several reasons; by main section of the guidelines, that gives:

In May 2026, Apple itself linked the rise in submissions to AI development tools. In June 2026, it clarified its spam guideline (4.3) and added examples; the specialist press read it as a response to mass-produced apps.

The guidelines that most often trip up generated apps

Pierre-Laurent Medori, Head of Backend Engineering at GoodBarber, adds a field detail on guideline 4.2: in the experience of GoodBarber’s publishing team, reviewers routinely test apps offline. A wrapped web app that shows a blank screen gives itself away.

Since May 2024, Apple has also required a privacy manifest: a file declaring the data collected and justifying the use of certain system interfaces. Common libraries (Capacitor, Flutter, the React Native engine) must provide one.

The privacy policy matters just as much. As Pierre-Laurent Medori points out, before Apple publishes an app, a reviewer opens its privacy policy link. A dead page, or a policy that forgets the analytics tool inside the app, is enough to hold a launch back.

What about the Replit, Vibecode and Anything blocks?

In spring 2026, Apple blocked updates of Replit and Vibecode, then pulled the Anything app from the App Store, under guideline 2.5.2. These measures targeted apps that generate and run other apps inside themselves, not the apps their users build and then publish separately. An Apple spokesperson told MacRumors the rule was not aimed specifically at vibe coding apps. Replit shipped a new update in May 2026 after reaching an agreement with Apple.

The checklist before you submit

Dominique Siacci, CTO of GoodBarber, describes two families of rejections: apps that look unfinished, and declarations that don’t match the app. His method: turn each lesson into a check you run before the store sees the app. The list below covers both families.

• No placeholder text, no empty screen, no button without a destination
• The app runs on a real phone without crashing, including when the network drops
• The app offers something a website doesn’t: notifications, offline use, camera, phone features
• The description and screenshots show exactly what the app does
• A demo account is provided in the review notes if the app requires sign-in
• Account deletion is possible from within the app
• Data sent to an AI or another third party is disclosed and accepted by the user
• The privacy policy is online, and the privacy declarations cover third-party tools
• The app is submitted under your own developer account
• No hidden or disabled feature is left in the app

What our own numbers show

At GoodBarber, the publishing team (GoodBarber Takes Care service) measures that about 42% of first iOS submissions are rejected by Apple over the last 12 months (internal figures, April 2026). After fixes, 91% of those apps end up accepted. On updates, the rejection rate drops to 5%. These figures don’t compare directly with Apple’s: its 23% rejection rate mixes new apps and updates, while our 42% covers first submissions only. They show that a first rejection is common, even for carefully built apps.

Our take

An Apple rejection is not a penalty against AI: it is almost always a sign that the app isn’t a real app yet. The work left after generation (finishing the screens, writing an accurate listing, handling data) is exactly what gets an app through review. If you don’t want to do it yourself, choose a tool or a provider that handles submission and fixes: at GoodBarber, that’s the role of the GoodBarber Takes Care service.