- My project: Hermes IDE | GitHub
- Me: gabrielanhaia
No Announcement. Just Rejections.
There was no WWDC slide. No carefully PR-tested blog post. No "letter to developers" from Tim Cook expressing deep concern for user safety.
Apple just started killing vibe coding apps. Quietly. One rejection at a time.
Replit's mobile app got hit first. Then Vibecode. Then a growing list of smaller AI-powered coding tools that had the audacity to let people build software on their iPhones. All of them received the same cold, templated rejection email referencing Guideline 2.5.2.
The apps still technically work if they're already installed. But they can't ship updates. Can't fix bugs. Can't add features. They're frozen, slowly decaying on millions of devices while Apple pretends nothing happened.
Here's the thing: everybody building on iOS should have seen this coming. Apple has a long, well-documented history of pulling exactly this move. The surprise isn't that it happened. The surprise is that anyone was surprised.
What the Rejection Actually Looks Like
Most developers outside the iOS world have never seen an App Store rejection email. They're something special. Here's approximately what lands in the inbox:
From: Apple App Store Review
Subject: Your app submission requires changes
Dear Developer,
We found that your app does not comply with the following
App Store Review Guidelines:
Guideline 2.5.2 - Performance
Apps should be self-contained in their bundles and may not
read or write data outside the designated container area,
nor may they download, install, or execute code which
introduces or changes features or functionality of the app,
including other apps.
Next Steps: Please review your app and make the necessary
changes to bring it into compliance.
Best regards,
App Store Review
No phone call. No negotiation. No explanation of which specific behavior triggered the rejection. Just a form letter and a link to a guideline that's been on the books since 2010.
The developer can appeal. Appeals go to a different review team that, in practice, almost always upholds the original decision. It's Kafka with a Cupertino mailing address.
The Actual Guideline Text (Read It Carefully)
Here's what Guideline 2.5.2 says in its current form, straight from Apple's developer documentation:
2.5.2 Apps should be self-contained in their bundles and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
That second sentence is doing a lot of heavy lifting. Educational apps get a carve-out. But who decides what counts as "educational"? Apple does. And Apple has decided that vibe coding apps don't qualify.
Swift Playgrounds, Apple's own learn-to-code app, compiles and runs arbitrary Swift on-device. It fits neatly into the educational exception. Funny how that works when the platform owner writes the rules and picks the winners.
Why Vibe Coding Scares Apple More Than Pythonista Ever Did
Pythonista has been running arbitrary Python on iOS for over a decade. iSH emulates a full Linux shell. There are Lua interpreters, JavaScript playgrounds, and BASIC emulators scattered across the App Store. Apple never cared much about any of them.
So why the crackdown now?
Because vibe coding changed the economics. Before AI got involved, mobile code editors were toys for developers. A niche within a niche. Some hobbyist runs a Python script on their iPad to parse a CSV file. That's not a threat to anyone's business model.
Vibe coding blew that up. When a 14-year-old on a school bus can say "build me a habit tracker with streaks and push notifications" and get a working app in three minutes, that's not a toy anymore. That's a parallel software distribution channel running inside Apple's walled garden, completely outside Apple's control.
For context: "Vibe coding" took off in late 2025 when AI code generation got reliable enough that non-programmers could describe apps in plain English and get functional results. Tools like Replit, Vibecode, and others brought this to mobile.
Every app generated inside one of these tools is an app that never goes through App Store review. Never pays Apple's 30% commission. Never asks Apple's permission to exist. The user doesn't even need a $99/year developer account.
That's not a bug Apple wants to fix. That's a business model Apple wants to destroy.
Apple's Security Argument Has Holes You Could Drive a Truck Through
The official line, to the extent Apple has bothered to articulate one, is security. Dynamically generated code is unpredictable. AI might produce vulnerable apps. Users could get hurt.
Not entirely wrong. AI-generated code does have security problems. LLMs hallucinate API calls, introduce injection vulnerabilities, and sometimes produce code that compiles perfectly and fails catastrophically. Anyone who's reviewed AI-generated PRs knows this.
But the security argument collapses under about thirty seconds of scrutiny.
The sandbox problem. Code generated by vibe coding apps runs inside a sandbox that's more restrictive than what normal App Store apps get. Replit's mobile runtime can't touch the iOS file system. Can't access the keychain. Can't activate the camera. A vibe-coded habit tracker is less dangerous than half the apps in the App Store's top 100.
The Safari problem. Every single website running JavaScript in Safari is executing dynamically downloaded, user-fetched code. WebView-based apps do the same thing. React Native apps pull JavaScript bundles from remote servers. Apple doesn't block any of this. If dynamic code execution were genuinely the concern, Safari would be the first app to get rejected.
The process problem. When Apple cares about security, it works with developers. It publishes technical requirements. It creates entitlement frameworks. It holds sessions at WWDC. That's the Apple security playbook, and it works well. None of that happened here. Developers got a rejection email with zero path to compliance. That's the Apple revenue-protection playbook, and it also works well, just for different reasons.
Follow the Money
Strip away the guideline citations and the security theater. What's left?
The App Store generated an estimated $24 billion in commission revenue in 2025. That number depends entirely on one thing: apps being distributed through the App Store. Every alternative distribution channel is a leak in Apple's revenue pipe.
Vibe coding apps aren't just a leak. They're a fire hose pointed at the foundation.
Think about the math. If even 5% of casual app creation moves to vibe coding tools over the next two years, that's millions of small apps that would have been submitted to the App Store, complete with in-app purchases and subscriptions funneling revenue through Apple's SKAdNetwork, that now exist entirely outside Apple's monetization infrastructure.
Apple doesn't need to prove that vibe coding is dangerous. Apple needs vibe coding to not exist on iOS. The guideline is the weapon. Security is the excuse.
This is the same company that blocked xCloud and Stadia from streaming games to iOS, citing the inability to review each individual game. The real issue was identical: game streaming threatened the App Store's cut of iOS gaming revenue. Apple eventually backed down under regulatory pressure, but only after extracting concessions that kept its commission structure intact.
The vibe coding fight is xCloud round two. Same strategy, different target.
The Community Response: Anger, Then Migration
Developers who built businesses around mobile vibe coding reacted predictably. Anger first. Then the pragmatic ones started moving.
Some shifted their users to Android, where Google's Play Store policies are significantly more permissive around code execution. Others went web-first, building Progressive Web Apps that run entirely in the browser and don't need any app store's permission. A few are experimenting with EU sideloading under the Digital Markets Act, distributing directly to European iPhones.
The irony is brutal. Apple's attempt to keep software creation inside the App Store is pushing creators off iOS entirely. Teachers who used vibe coding apps in classrooms are switching to Chromebooks. Indie developers who taught workshops on "build your first app on your iPhone" are rewriting their curricula around web tools.
Where vibe coders are going now:
- Moving to Android -- Google doesn't care.
- Going web-only -- Apple can't block browsers... yet.
- EU sideloading -- thank you, Brussels.
- Waiting for Apple to blink -- could be a while.
Option 4 is the worst bet. Apple doesn't blink. It calculates. It'll hold this position until the cost of holding it exceeds the cost of conceding. Right now, the cost of holding is low. Vibe coding is still niche enough that the backlash stays inside tech Twitter.
The Deeper Question Nobody Wants to Answer
For most of computing history, if someone owned hardware, they could run whatever code they wanted on it. Buy a PC, install GCC, compile anything. That was the deal. Nobody sat between the developer and the machine.
The App Store changed that arrangement. Apple introduced the idea that a platform owner should review and approve every piece of software running on hardware that the user purchased and owns. The pitch was quality and security. The result was something unprecedented: a private company with veto power over what software a billion people can use.
Vibe coding threatens that arrangement in a way that sideloading and alternative app stores never did. When an AI generates a functional app inside a sandboxed runtime on a phone, there's no binary to review. No submission to approve. No bundle to inspect. The "app" exists ephemerally inside another app, conjured on demand by a user who might not even know what an API is.
App Store review becomes meaningless when apps don't have a fixed form. Apple's entire gatekeeping apparatus assumes software is a static artifact that gets submitted, reviewed, and distributed. Vibe coding treats software as a conversation. Apple literally doesn't have a process for reviewing a conversation.
That's what makes this different from previous fights. Sideloading was a policy problem. Vibe coding is a category problem. Apple can regulate sideloading with notarization requirements and alternative payment rules. How do you regulate something that's generated fresh every time a user types a sentence?
Three Ways This Plays Out
Hold the line. Vibe coding stays banned on iOS. The tools migrate to web and Android. A generation of new creators associates iPhones with "the device where you can't build things." Apple keeps its commission revenue but loses cultural relevance with the next wave of builders. This is what's happening right now.
Cut a deal. Regulatory pressure from the EU (and possibly the US DOJ, which is still pursuing its antitrust case) forces Apple to create a "code generation" app category with specific technical requirements. Apple gets some oversight and probably a smaller commission on apps distributed through vibe coding platforms. Developers get back on iOS with restrictions. Nobody's happy, which means it's a compromise.
Co-opt it entirely. Vibe coding gets built directly into Swift Playgrounds, or Apple announces an "Apple Intelligence App Builder" at WWDC. Generated apps flow through a lighter review process into the App Store. Apple controls the entire pipeline from prompt to distribution. This is the smart long-term play, and it's probably where things end up in 2-3 years. But Apple will exhaust the first two options before getting here, because that's what Apple always does.
The EU angle matters more than most people realize. The Digital Markets Act already forced Apple to allow sideloading and alternative app stores in Europe. If the European Commission views the vibe coding ban as anti-competitive gatekeeping of a new software distribution method, Apple could face another round of mandated openness. And this time, the precedent from the sideloading fight means the regulatory machinery is already warmed up.
The Uncomfortable Truth About Platform Risk
Every developer building exclusively on a closed platform is a tenant, not an owner. The landlord can change the lease whenever it wants.
That's not some abstract principle. It's what just happened to every vibe coding app on iOS. Developers who'd invested months of work, built user bases, and generated real revenue got a form email and a brick wall. No negotiation. No transition period. No empathy.
The developers who'll survive this are the ones who never treated iOS as their only channel. Cross-platform from day one. Web version alongside native. PWA as a fallback. These aren't just architectural decisions. They're insurance policies against exactly this kind of platform risk.
For the vibe coding community specifically, Apple's ban might accidentally be the best thing that could have happened. It's forcing these tools to build on open foundations before they got too dependent on a closed one. Better to learn this lesson at 100,000 users than at 10 million.
What This Is Really About
Apple didn't block vibe coding apps because they're insecure -- the sandboxing in these tools is tighter than most App Store apps. It wasn't about Guideline 2.5.2 either; that rule has been selectively enforced for sixteen years, applied when convenient and ignored when profitable.
The real reason is simpler: vibe coding represents a future where a billion iPhone owners can create software without asking Apple's permission or paying Apple's tax. That future is coming whether Apple likes it or not. The only question is whether Apple will adapt to it or spend the next five years fighting it with lawyer-drafted rejection emails.
History suggests the fighting comes first. The adapting comes later. And the developers caught in between pay the price for Apple's timeline.
What's your read on this? Revenue protection dressed up as security policy, or does Apple have a legitimate technical case? If the vibe coding rejections hit your workflow, share what happened below. The more documented cases, the harder these become for Apple to quietly maintain.
Top comments (0)