Apple Guideline 2.5.2: The Vibe Coding Crackdown

Apple is cracking down on dynamic code. Many apps will be rejected

In early 2026, Apple quietly blocked several popular development apps from releasing updates. Replit, Vibecode, and similar tools that let users build and deploy apps from their phones hit a wall. The reason: guideline 2.5.2.

This wasn't a new rule. Section 2.5.2 of Apple's App Review Guidelines has existed for years. But Apple is now enforcing it more aggressively against a category of apps that barely existed two years ago: AI-powered "vibe coding" tools that generate, download, and execute code at runtime.

If your app dynamically loads or executes code that wasn't part of the original binary, this matters to you too.

What does guideline 2.5.2 actually say?

Guideline 2.5.2 requires that apps be self-contained in their bundles. Apps may not download, install, or execute code that introduces or changes features or functionality of the app; the guideline's own text carries a narrow exception for educational apps that let students view and edit downloaded teaching code. The exception that actually shapes most production apps sits in a companion document: the Developer Program License Agreement, section 3.3.2, permits interpreted code run by the built-in WebKit framework or JavaScriptCore, as long as the scripts don't change the app's primary purpose. Everything else needs to be in the binary at review time.

The principle behind this is straightforward. Apple reviews the app you submit. If your app can change its own behavior after review by downloading new code, Apple's review process becomes meaningless. You could ship a calculator and turn it into a social network after approval.

This has always been the rule. What changed is the category of apps that now rely on exactly this pattern.

What triggered the enforcement?

The rise of AI-assisted code generation created a new class of apps. Tools like Replit, Vibecode, and others let users describe what they want in natural language, generate the code using an LLM, and run it directly on the device. Some go further: they package the generated code into standalone apps that users can install.

Apple flagged this because these apps introduce entirely new functionality after review. The app you review is a code editor. The app the user experiences could be anything.

According to 9to5Mac's reporting, Apple pulled the app "Anything" from the App Store entirely and blocked updates for others. The enforcement isn't limited to small developers. Replit is a well-funded, widely used platform.

Which apps are affected?

The enforcement targets apps that:

• Generate code dynamically (via AI or other means) and execute it on-device
• Download executable code or scripts that alter the app's functionality
• Act as runtime environments for user-generated applications
• Package or distribute apps within apps

This goes beyond just "vibe coding" tools. If your app includes a scripting engine, plugin system, or dynamic module loader that fetches code from a server, you're in the same territory.

Apps that use server-side rendering and only display results in a WebView are generally safe. The line is at code execution on the device, not at content delivery.

What about legitimate use cases?

Many established apps use some form of dynamic code. React Native apps load JavaScript bundles. Game engines download asset packs with scripting. Enterprise apps push configuration changes.

Apple's enforcement distinguishes between patterns based on whether they change the app's functionality after review:

Pattern	Status	Reason
JavaScript in JavaScriptCore/WKWebView	Allowed	No change to app's primary purpose
Web content loaded in WebKit	Allowed	Standard content delivery
Server-driven config / feature flags	Allowed	Data changes, not code changes
OTA JS bundle updates (CodePush, EAS Update)	Allowed, within limits	Permitted under the WebKit/JavaScriptCore exception as long as the downloaded code does not change the app's primary purpose or introduce behavior the reviewer never saw; risk concentrates where it does
Downloading native code (Swift, ObjC, C++)	Not allowed	Bypasses review entirely
Runtime code generation (dlopen, JSC eval for new features)	Not allowed	Violates 2.5.2 directly
Building/installing standalone apps within an app	Not allowed	Creates unreviewed apps
Plugin systems adding post-review functionality	Not allowed	Features not present at review time

The "primary purpose" qualifier is what separates allowed from not allowed. React Native's hot-reload in development mode technically violates the spirit of 2.5.2, but Apple has tolerated JavaScript bundle updates in production because the core functionality doesn't change. AI-generated apps are different because the entire purpose is creating new functionality. The app you submit as a code editor becomes whatever the user asks the AI to build.

How to check if your app is at risk

Review your app for these patterns:

Runtime code execution Search your codebase for usage of dlopen, NSBundle loading from non-app-bundle paths, or calls to system() and popen(). Any of these loading external code will trigger scrutiny.

JavaScript execution outside WebKit If you use JavaScriptCore directly, verify that scripts are bundled with the app or loaded from your own server for configuration purposes only. Scripts that introduce new UI screens or features cross the line.

Plugin or extension systems If your app supports plugins that users or third parties can install after the initial download, that's a 2.5.2 risk. Even if the plugins are written in a scripting language.

Dynamic feature modules Android's dynamic feature modules have an iOS equivalent in on-demand resources. But on-demand resources deliver assets, not executable code. If you're downloading code modules on demand, you're violating 2.5.2.

Check your Info.plist and privacy manifests for any custom URL schemes or document types that suggest your app processes external code files. And audit your network requests: if your app downloads anything that gets executed, document why it falls under an exception.

What happens if Apple flags your app?

Based on recent enforcement patterns, Apple's response is graduated:

1. Update rejection: your next binary upload is rejected with a reference to 2.5.2
2. Required changes: Apple specifies what needs to be removed or altered
3. App removal: in severe cases, the app is pulled from the store entirely

The "Anything" app was removed outright. Replit and others received update blocks with requirements to change their functionality. There's no public appeals process specific to 2.5.2, but you can respond through the Resolution Center in App Store Connect.

If your app is flagged, removing the dynamic code execution is usually the only path forward. Apple hasn't shown willingness to grant exceptions for AI-generated code execution.

Impact on CI/CD and build processes

For teams using CI/CD pipelines that build and submit IPA files, the 2.5.2 enforcement doesn't directly impact your build process. It's about what the compiled binary does at runtime, not how it's built.

But you can catch potential issues before submission:

• Scan your binary for dynamic loading symbols (dlopen, NSBundle with external paths)
• Audit embedded frameworks for scripting engines beyond JavaScriptCore
• Review any network calls that download executable content
• Check third-party SDKs for hidden code-loading behavior

AppCompliance scans compiled IPA, APK, and AAB files for binary-level indicators that can trigger store review issues, including dynamic code loading patterns. For more on what binary analysis can detect, see our deep dive. No tool can guarantee store approval, but detecting these patterns before upload prevents surprise rejections.

Where this is heading

With the iOS 26 SDK deadline approaching, Apple's enforcement of 2.5.2 is likely to intensify. The AI code generation trend isn't slowing down, and Apple has a clear incentive to maintain control over what runs on its platform. Developers building tools that generate or execute code dynamically should expect continued scrutiny.

For most app developers, 2.5.2 isn't a daily concern. Your standard UIKit or SwiftUI app, built and submitted through Xcode, doesn't touch these boundaries. But if your architecture includes any form of runtime code loading, now is a good time to audit it. Apple's tolerance for grey areas in this space is shrinking.