Inside Apple's War on Vibe Coding Apps: The Full Story So Far

What started as a quiet freeze on App Store updates in January has turned into the most significant platform enforcement story of 2026. Apple has blocked updates, pulled apps entirely, and drawn a hard line around what vibe coding tools can and can’t do on iOS. Meanwhile, App Store submissions have surged 84% year over year, the abandoned listing of one banned app got hijacked by scammers, and the vibe coding industry is being forced to rethink its relationship with mobile platforms from the ground up.

Here’s everything that’s happened, why it matters, and where it’s headed.

The Rule at the Center of All of This

Every enforcement action in this story traces back to one provision: App Store Review Guideline 2.5.2. The rule states that apps “may not download, install, or execute code which introduces or changes features or functionality of the app.”

There’s a narrow exception for educational coding apps where source code is “completely viewable and editable by the user.” But vibe coding apps don’t fit that exception cleanly. Their entire value proposition is generating and running code on the fly, which is exactly what 2.5.2 was written to prevent.

An Apple spokesperson has maintained that the company isn’t targeting “vibe coding” as a category. MacRumors reported that Apple frames this as routine enforcement of existing policy: keeping apps from changing what they do after passing review. But when every major vibe coding platform with an iOS app hits the same wall within a few months, calling it routine starts to feel generous.

January-March: The Quiet Freeze

The first signs appeared in late 2025. Apple began blocking App Store updates for at least two vibe coding apps: Replit and Vibecode. Both apps remained available for download, but no new updates could ship.

Apple conducted phone calls with both development teams over the following weeks, according to The Information, laying out what each company would need to change. The demands were different for each app.

Replit was told to stop previewing generated apps inside its iOS client. Instead, newly created software would have to open in an external browser like Safari. Replit pushed back, arguing its previews ran in a sandboxed virtual machine behind a web view, similar to how social media apps handle embedded links. Apple rejected that argument. As of the latest reporting, Replit is close to getting updates approved after agreeing to the external browser requirement.

Vibecode got a harder ask: remove the ability to generate software specifically for Apple devices. Apple’s review team reportedly indicated they’d likely approve updates if Vibecode made that change. That’s a significant concession to demand from a tool whose users specifically want to build iOS apps.

The Information broke the story publicly on March 18. 9to5Mac and MacRumors quickly followed.

Anything App: Pulled, Restored, Pulled Again

The most dramatic case involves Anything, a vibe coding platform co-founded by Dhruv Amin that lets non-developers describe an app idea in natural language and see it built on their phone.

Apple had been blocking Anything’s updates since December 2025. On March 26, Apple went further and pulled the app from the App Store entirely, citing Guideline 2.5.2. 9to5Mac and Apple Insider both covered the escalation.

What made it worse: Amin had already submitted an update designed to comply. The new version would preview vibe-coded apps in a web browser rather than rendering them natively inside the app. Apple blocked that update too, and then pulled the entire listing.

On April 3, Anything was permitted to return after making adjustments. But the reprieve didn’t last. As TechCrunch reported on April 14, the app has now been booted from the App Store twice total, and the team is currently rebuilding to meet Apple’s requirements.

The Anything saga has become the highest-profile example of how unpredictable Apple’s enforcement can be. Even good-faith attempts to comply aren’t guaranteed to work.

Rork: From Top 10 to Hijacked Listing

Rork’s story is different from the others and, in some ways, more disturbing.

Rork operated on a distinct model from Replit or Anything. Users could generate functional mobile apps via AI text prompts directly on their devices. At its peak, Rork hit #7 globally in the Developer Tools category in September 2025.

Then came Apple’s October 2025 policy enforcement. Apple prohibited apps that solicit Apple Developer credentials or execute external code occupying more than 80% of the screen. Rork’s model ran directly into both provisions.

Rather than fight for compliance, Rork’s creators abandoned the native iOS app entirely. They pivoted to a web-based product called “Rork Max,” which generates actual native Swift code that users compile and submit through their own developer accounts. The generated apps go through Apple’s normal review process, sidestepping the Guideline 2.5.2 problem completely.

But here’s where things went wrong. After Rork left the App Store, the original listing (App ID 6746410361) was hijacked. The listing was transferred to a publisher named “Carrie Roberts” and rebranded as “Rork: AI Coding with Rock.” The real features were stripped out and replaced with a subscription paywall. Weekly revenue briefly surged from $8,000 to $16,000 via what amounted to a bait-and-switch, riding the original app’s ratings and search ranking.

This is a cautionary tale that goes beyond vibe coding. When legitimate developers abandon App Store listings under regulatory pressure, those listings become targets for scammers. Apple’s review process, already strained, didn’t catch the hijacking before real users were affected.

The Numbers: An 84% Surge in Submissions

While Apple was tightening enforcement on vibe coding platforms, the tools themselves were driving a historic wave of new app submissions.

Sensor Tower data, first reported by The Information and covered by The Next Web and Apple Insider, paints a clear picture:

• Q1 2026: 235,800 apps submitted, an 84% year-over-year increase compared to Q1 2025
• Full-year 2025: 557,000 new app submissions, the largest annual wave since 2016
• December 2025: A 56% year-over-year spike in iOS app launches
• January 2026: A 54.8% rise over the prior January

Between 2016 and 2024, new app submissions to the App Store had actually fallen 46%. The trend reversed sharply in 2025, growing roughly 30% over 2024. Q1 2026 accelerated the reversal dramatically.

Sensor Tower analyst Abraham Yousef attributed the rise directly to agentic coding tools, specifically naming Claude Code and ChatGPT Codex as key drivers. The correlation between tool adoption and submission volume is hard to argue with.

This creates a genuine tension in Apple’s position. The company is simultaneously blocking the platforms that help people create apps while dealing with the consequences of those platforms’ success: more submissions than Apple’s review infrastructure was built to handle.

Apple’s Position: Enforcement, Not Targeting

Apple has been consistent in its public messaging. A spokesperson told MacRumors and PYMNTS that the company has no rules specifically against “vibe coding” apps. The App Review Guidelines are “designed to encourage innovation while preserving safety for users.” This is enforcement of Guideline 2.5.2, which has existed for years.

There’s truth in that framing. The rule predates vibe coding by a long time. It was originally written to prevent apps from downloading and executing code that fundamentally changes what the app does after passing review. Vibe coding tools, by their nature, do exactly that. A coding app that passed review as a development tool can produce a fully functional shopping app, game, or social network running inside itself. Apple’s review process was never designed for apps whose functionality is unbounded.

Apple is also reportedly testing automated App Store review tools to help manage the increased volume. That’s a logical response to the submission surge, but it doesn’t resolve the core tension around what vibe coding apps are allowed to do on iOS.

What’s Actually Allowed Now

Based on the enforcement patterns so far, here’s what the boundaries look like for vibe coding tools on iOS:

Still fine: Apps that generate code and let users view, copy, and export it. The code itself isn’t the problem. Tools like v0 (by Vercel) have continued shipping App Store updates without issues, likely because their architecture already handles previews through external browsers or meets Apple’s requirements for code display.

Requires changes: Previewing generated apps in-app through web views. Apple wants these previews to open in Safari or another external browser. It’s clunky, but it’s the compromise Replit accepted.

Not allowed: In-app execution of generated code that effectively creates new, unreviewed applications running inside the host app. This is the core of Guideline 2.5.2. If the generated output occupies most of the screen and functions as an independent app, Apple will block it.

Risky territory: Generating code specifically for Apple platforms. Vibecode was told to remove this capability entirely. Whether that requirement extends to other tools isn’t clear, but it signals that Apple views platform-specific code generation as a competitive threat, not just a review process problem.

The Web-First Pivot

The most significant long-term effect of Apple’s crackdown is the accelerating shift toward web-based vibe coding.

Rork’s pivot from a native iOS app to “Rork Max,” a browser-based tool that generates native Swift code, is the clearest example. By moving the code generation to the web, Rork avoids Guideline 2.5.2 entirely. The apps its users build still go through Apple’s normal review process, but Rork itself doesn’t need App Store approval to operate.

This pattern is spreading across the industry. Web-based platforms like Bolt and Lovable were never subject to these restrictions in the first place. They generate apps that users deploy wherever they want, including as progressive web apps that bypass the App Store entirely.

That last point is worth underlining. Every time Apple pushes a vibe coding tool off iOS, it increases the chances that the apps those tools create won’t end up on the App Store either. Users who get frustrated with App Store friction learn about progressive web apps, installable web apps, and direct distribution. Apple’s enforcement, intended to protect the App Store’s integrity, may be accelerating the very trend it should want to prevent: the migration of app distribution away from Apple’s controlled ecosystem.

What to Watch Next

Several threads are still developing.

Anything’s third attempt. The team is currently rebuilding after two removals. Whether they find a stable architecture that Apple will accept on a lasting basis will set a precedent for every other vibe coding app considering iOS.

Apple’s next guideline update. The November 2025 update added anti-copycat rules and AI data-sharing disclosure requirements, but nothing specifically addressing vibe coding or AI code generation. The next update could formalize what’s currently being enforced on a case-by-case basis, or it could leave the ambiguity in place, giving Apple’s review team room to make judgment calls.

The EU factor. European regulators have been scrutinizing Apple’s App Store gatekeeping under the Digital Markets Act. If Apple’s vibe coding enforcement gets framed as anticompetitive restriction of developer tools, it could draw regulatory attention.

Automated review at scale. Apple processing 200,000+ submissions per week with human review is unsustainable at the current growth rate. How quickly Apple scales its automated review capabilities will determine whether the 84% submission surge becomes a quality crisis or just a scaling challenge.

The vibe coding wave isn’t slowing down. The tools are getting better, more accessible, and more popular every month. Apple’s enforcement is a significant obstacle for iOS-native vibe coding, but it’s also pushing the entire ecosystem toward the open web, where Apple has less control. That dynamic is going to define the next chapter of this story.