Safe by design: why Buildy survives Apple's 2.5.2

Apple pulled dozens of AI app builders under Guideline 2.5.2 in March 2026. Buildy was architected so that rule could never apply to the apps you build with it.

In March 2026, Apple started pulling AI app builders from the App Store. Replit Mobile went first. Create.xyz (formerly Anything) followed. A handful of others disappeared inside a 48-hour window — some reinstated, then pulled again. The rule behind all of it was App Store Review Guideline 2.5.2.

What 2.5.2 actually says

The guideline is short: apps "may not download, install, or execute code which introduces or changes features or functionality of the app." In plain terms, an app on a phone has to be self-contained. It can't fetch new code at runtime and run it.

That is exactly what the pulled builders did. The pattern was identical across every one of them:

1. The user opens the AI-builder app on their phone.
2. The app accepts or downloads user-generated code at runtime.
3. An embedded webview or JavaScript engine executes that code.

Step three is the violation. The moment a shipped binary runs code it didn't carry through review, it's in breach — and Apple began enforcing that against this whole category on March 30, 2026.

Why this doesn't apply to Buildy

Buildy is a build tool, not an engine that runs inside your users' apps. The distinction sounds subtle. Architecturally it's the whole ballgame.

When you build with Buildy, two completely separate things exist:

• The editor and preview. These live at buildy.me, on our servers. When you click an element in the live preview, Buildy compiles your code server-side and renders it in a sandboxed iframe. The preview engine never leaves our infrastructure. It is never bundled into anything that reaches a phone.
• The app you ship. That's ordinary React Native and Expo source. EAS Build compiles it to a signed .ipa or .apk. The binary on the App Store contains zero code execution, zero remote loaders, zero 2.5.2 surface.

The builders that got pulled blurred those two things into one. The preview engine was the shipped app. We never wired it that way, and there is no setting we could flip tomorrow to break this — it's how the architecture is built.

Why we made this choice early

Server-side preview is harder to build than embedding a runtime in the app. An in-app JavaScript engine is the path of least resistance: bundle it once and every preview is free. We didn't take that path, and for a while it looked like extra work for no payoff. Then 2.5.2 enforcement arrived and the payoff was the entire category staying out of the rejection lottery.

There's a second benefit that falls out of the same decision. Because the preview runs on our servers and the export is plain source, the code you ship is exactly the code you can read, audit, and own. No proprietary runtime gets stitched in at build time. (More on that in Your code is yours.)

What this means for you

If you've watched competitors get delisted and wondered whether building a mobile app with AI is worth the risk, this is the answer: the risk those products carried was an architectural choice, not an inherent property of AI app building. Buildy made the other choice.

You describe the app. We generate React Native source. You preview it safely on our servers, export it whenever you want, and ship a normal signed binary that has nothing to hide from review.

Build mobile apps without the rejection lottery. Start building free.