Apple tightens App Store rules, bars post‑review dynamic code edits

Apple’s App Store fight here is not really about “AI” in the abstract. It’s about code that changes after review. And Apple seems to be drawing that line more sharply now — especially for apps that generate, fetch, or swap in new behavior once they’re already on a user’s iPhone. The result is a problem for vibe-coding tools, autonomous agents, and any app that wants to feel more like a live software container than a fixed product. (developer.apple.com) ### What rule is Apple leaning on? The rule is App Store Review Guideline 2.5.2. Apple’s current wording says apps should be self-contained in their bundles and may not download, install, or execute code that introduces or changes features or functionality. That language is not new. What matters is that Apple has long paired it with rejection notices saying even the *capability* to change behavior after review can be enough to fail. (developer.apple.com) ### Why does that suddenly matter more? Because a lot of new AI products work by turning prompts into fresh logic on the fly. That is basically the whole magic trick. A user asks for a tool, workflow, or mini-app, and the system generates code or script-like behavior in response. On the web, that is normal. Inside a reviewed iOS app, Apple can treat that as unreviewed functionality arriving after the fact. (developer.apple.com) ### What kinds of apps get squeezed? Two buckets stand out. First, vibe-coding apps — tools that let users create or run software from natural-language prompts. Replit has been pushing mobile app creation on iOS, including “idea to App Store” messaging and an iOS software-creation agent. Second, agent apps that can alter workflows, tools, or task logic remotely after approval. If the app’s real b(developer.apple.com)s not the real product. (replit.com) ### Isn’t remote content already normal on phones? Yes — but content is not the same as executable behavior. Apple has always allowed apps to fetch data, media, and server-driven content. The catch is when that remote payload effectively becomes new app logic. Apple’s old rejection language even calls out remote scripts, `dlopen`, `dlsym`, and arbitrary dynamic method calls as examples of mechanisms that can change behavio(replit.com) fine; shipping a hidden second app through the network is not. (developer.apple.com) ### What about On-Demand Resources? That is where some developers seem to be looking for a compliant path. Apple does let apps fetch Apple-hosted asset packs later through On-Demand Resources, but those are still reviewed resources tied to the app package — not a loophole for mutable live code. The forum traffic around ODR shows developers trying to manage large packaged assets and versioned resources, but the system is built for assets, not post-review code swaps. (developer.apple.com) ### Why does Apple care so much? Security and review control. Apple’s rejection text says remote code paths could be hijacked and used to load private frameworks, private methods, or future features Apple never examined. That is the core issue — if behavior can materially change after approval, App Review stops being the gate. Apple would rather force developers to submit a new binary than let apps quietly become something else later. (developer.apple.com) ### So what do developers have to do now? They need to make behavior more deterministic and reviewable. That usually means keeping executable logic in the shipped app, moving open-ended generation to the web, or limiting iOS clients to rendering reviewed templates and server results rather than executing fresh code locally. It is a worse fit for “build anything live on your phone” products, but a better fit for Apple’s model of a fixed, inspectable app. (developer.apple.com) ### Bottom line? Apple did not invent a brand-new anti-AI rule. It is enforcing an old anti-dynamic-code rule against a new class of apps. And that matters because many AI-native mobile products are built around exactly the kind of post-review flexibility Apple has spent years trying to prevent. (developer.apple.com)