Will Apple Reject an AI-Generated App? What Guideline 2.5.2 Actually Says (2026)

In March 2026, Apple quietly stopped several AI app-building platforms from shipping App Store updates. Replit and Vibecode were both blocked; a third app, Anything, was removed from the store entirely at the end of that month. The rule cited in each case was Guideline 2.5.2.

Understandably, a lot of people building with AI tools have since asked the same question: is the app I'm building going to get rejected?

The answer is more specific — and more reassuring — than the headlines suggest. Apple has not banned AI-generated apps. What it has enforced is a rule about how apps run code, and whether you're affected depends entirely on the architecture of the tool you used. Here's the actual distinction.

What Guideline 2.5.2 says

The rule long predates AI. In plain terms, it requires that an app be self-contained in its own bundle, and prohibits an app from downloading, installing or executing code that introduces or changes features and functionality.

The reasoning is a safety one. Every app on the App Store goes through review. If an app can pull down new code after review and change what it does, then the reviewed version isn't the version users are running, and the review has been bypassed.

That rule has sat in the guidelines since the early days of the App Store. Nothing about it was written with AI in mind.

Why AI builders ran into it

The platforms that got blocked shared a common design: you type a prompt, the AI generates an app, and that generated app is then previewed inside the builder app itself, in an embedded web view.

That's the part Apple objected to. The host app is executing code it downloaded after review, and that code changes what the app does. It's the exact scenario 2.5.2 describes.

Reporting at the time indicated Apple was close to approving the blocked platforms once they agreed to change how generated apps are previewed — opening them in an external browser rather than in-app — or, in one case, to drop the ability to generate software for Apple platforms at all.

Apple's own position was that this wasn't a policy aimed at AI tools specifically. It was existing rules applied to a new pattern.

The distinction that actually matters

This is the part worth internalising, because it determines whether any of this affects you:

The issue is runtime code execution, not AI authorship.

Apple does not care whether a human or a model wrote your Swift. There is no rule against using AI to write code, and there is no way for a reviewer to tell. What Apple cares about is whether an app executes code it fetched after review.

That splits AI app builders into two architectural camps:

Camp one — interpreted at runtime. The tool generates code (usually HTML, JavaScript or a JS bundle) which is loaded and run inside a host app or a web view. The generated "app" isn't compiled; it's interpreted live. This is what 2.5.2 catches. It's also the same split we covered in why most AI app builders only make web apps.

Camp two — compiled to a native binary. The tool generates real source code, compiles it with Apple's own toolchain into a signed binary, and that binary is what gets submitted. Nothing is fetched or executed at runtime — the reviewed build is the shipped build, exactly as with any hand-written app.

Apps in the second camp are architecturally in the same position as a traditionally-developed app, because that is structurally what they are. The AI replaced the typing, not the toolchain.

There's a related rule worth knowing about too. Guideline 4.7 creates a narrow allowance for HTML5 and JavaScript mini apps hosted inside a larger app — but it comes with conditions, and a 2025 clarification made explicit that apps offering non-embedded software may not extend or expose native platform APIs to that software without Apple's prior permission. So the mini-app carve-out doesn't rescue anything that wants real native device access.

What this means for the app you're building

Three practical checks:

1. Does your generated app run inside another app? If you preview and run your creation inside a host app on your phone, that's the affected pattern.
2. Do you get a compiled binary? If the output is an .ipa built with Xcode and submitted to App Store Connect, you're on the compiled side.
3. Can you export the source? A tool producing a real Xcode project you could open and inspect is producing real native code. That's a good proxy for camp two — and it's also your insurance against any platform's future problems, because the code isn't trapped.

If your app was built with an affected tool and is currently stuck, the route forward is usually a rebuild on a compiled-native architecture rather than an appeal. Our rundown of the best AI app builders for iOS in 2026 splits the field along exactly this line.

The other thing that changed: review times

Worth setting expectations on, because it affects everyone regardless of architecture.

The AI-building wave produced a very large increase in App Store submissions — reporting from The Information put the rise at 84% in a single quarter. Apple's review queue absorbed that unevenly. Developers submitting in March 2026 reported waits of anywhere from a week to a month or more, against a historical norm of roughly 24 to 48 hours.

That has eased since, but if you're planning a launch, build in more slack than the old guidance suggests. And expect scrutiny on the things reviewers are now primed to look for in AI-built apps: thin functionality, missing privacy disclosures, exposed API keys, and apps that don't do enough to justify existing. If you're getting close to submitting, how to publish an iPhone app to the App Store walks through the rest of it.

Where Orchard sits

Orchard is a compiled-native builder. It generates real Swift and SwiftUI source, compiles it with Xcode on real Macs, signs it, and submits that binary to TestFlight and the App Store. Your app doesn't run inside Orchard on anyone's phone — there is no host app, no embedded web view, and no code fetched at runtime. You also get the full Xcode project, so the source is yours to inspect, edit or take elsewhere.

We'd rather be straight about the limits of that claim: no one can promise an App Store approval, and Apple can change or reinterpret its guidelines whenever it likes. Apps still get rejected for thin functionality, metadata problems and privacy issues, and an AI-built app is not exempt from any of that.

What we can say is narrower and more useful: the specific rule that caused the March 2026 blocks describes a pattern Orchard's architecture doesn't use.

FAQ

Does Apple ban AI-generated apps? No. There is no rule against using AI to write an app's code. Apple's enforcement targeted apps that download and execute code at runtime, which is a question of architecture rather than authorship.

What is Guideline 2.5.2? It requires apps to be self-contained and prohibits downloading, installing or executing code that introduces or changes features and functionality. It exists so that the version Apple reviews is the version users actually run.

Why were Replit and Vibecode blocked? Both previewed AI-generated apps inside their own app using embedded web views, which Apple treated as executing downloaded code that changes functionality.

Can I still publish an app I built with AI? Yes, provided the app itself is a normal compiled native binary and meets the usual guidelines on functionality, privacy and metadata.

How can I tell if my builder is affected? Ask whether the output is a compiled binary submitted to App Store Connect, or code interpreted at runtime inside a host app. If you can export a real Xcode project, it's the former.

Want a real compiled native app rather than a web view? Orchard generates genuine SwiftUI, builds it with Xcode, and ships it to the App Store.