Apple is pulling vibe-coding apps, and honestly, we get it

What happened

Last Thursday, Apple removed an app called Anything from the App Store. Anything let people build and preview mobile apps on their iPhone using natural language prompts, no coding required. The app had raised $11 million at a $100 million valuation and its users had reportedly published thousands of apps through the platform.

The reason for the removal? Guideline 2.5.2, the same rule Apple has been using all month to crack down on this category. The guideline says apps must be "self-contained" and cannot "download, install, or execute code which introduces or changes features or functionality of the app." Earlier in March, Apple had already blocked updates to two other vibe-coding platforms, Replit and Vibecode, citing the same rule.

What makes the Anything situation particularly messy: the developer actually tried to comply. After Apple flagged the issue, Anything's co-founder submitted an update that moved app previews to a web browser instead of rendering them inside the app. Apple rejected the update and pulled the app entirely. Meanwhile, similar apps remain live on the store. Apple hasn't explained the inconsistency.

This isn't really about one app

Let's be clear about what's happening here. Apple isn't saying "no" to AI-assisted development. Their own Xcode now ships with AI coding features. What they're saying is: you don't get to build a mini runtime inside an iOS app that generates and executes unreviewed code on-device. That bypasses the entire App Review process, and from Apple's perspective, that's the line.

I think Apple is right to draw it, even if the enforcement feels inconsistent and the communication has been poor.

In our native iOS and Android work, we've dealt with App Review rejections more times than I can count. The rules have always been strict, but they've also always been somewhat opaque. You learn to read between the lines over years of submissions. What's different now is the speed at which a whole new category of apps, vibe-coding tools, slammed into a guideline that was written long before anyone imagined this use case. Apple is clearly figuring out its enforcement approach in real time, app by app.

That's uncomfortable for the startups getting caught in the middle, but it's also the reality of building on someone else's platform.

The deeper problem nobody wants to talk about

Here's what gets me about the vibe-coding hype in general, and this goes beyond the App Store fight.

A recent survey of 700 engineers found that 69% of developers who use AI coding tools very frequently report deployment problems "always, nearly always, or frequently" when AI-generated code is involved. Among the heaviest users, 22% of deployments result in a rollback, hotfix, or customer-impacting incident. And 53% report more security vulnerabilities since adopting these tools.

So we're not just talking about Apple being a gatekeeper. We're talking about a flood of code being produced faster than anyone can properly review, test, or deploy it. Main branch success rates have dropped to 70.8%, a five-year low. The bottleneck isn't writing code anymore. It's everything that happens after.

Now imagine that dynamic applied to people with zero coding experience building apps through natural language prompts and shipping them to the App Store. The quality control problem gets exponentially worse.

When we build cloud-native apps for enterprise clients, especially in regulated industries like healthcare and finance, we spend as much time on our CI/CD pipelines and automated testing as we do on the application code itself. We've seen firsthand what happens when deployment velocity outpaces your guardrails. It's not pretty, and it doesn't matter whether a human or an AI wrote the code.

What this means for teams building on iOS

If you're building a tool that generates or executes code on iOS, you need to pay attention to this. Apple has drawn a clear line, even if they're not enforcing it consistently yet. Some practical takeaways:

First, don't build your business on an assumption that Apple will let you run generated code inside an iOS app. Guideline 2.5.2 is old, well-established, and Apple is clearly willing to enforce it. If your architecture requires on-device code execution, you need a Plan B.

Second, if you're using vibe-coding tools to build apps for the App Store, understand that Apple's review process wasn't designed for this volume. Reports suggest these tools have contributed to a surge in submissions and slower approval times. Budget extra time and expect more scrutiny.

Third, and this applies regardless of whether you use AI tools: invest in your pipeline. Standardized templates, automated security scanning, feature flags, automated rollbacks. The data is clear that teams shipping AI-assisted code without these foundations are seeing more incidents, not fewer. From our PHP and Docker work with enterprise clients, the pattern is the same: speed without guardrails creates expensive problems.

The security angle

During our penetration testing engagements, we've started seeing a new pattern: AI-generated code that compiles, passes linting, and still contains exploitable vulnerabilities. The code looks clean on the surface. It follows conventions. But it doesn't account for the specific security context of the application it was written for.

One report described a fintech firm that committed AI-generated code without review and had a SQL injection exploited within 48 hours. That's a $1.2 million lesson in why "it works" isn't the same as "it's safe."

AI coding tools are trained on historical code repositories. They don't have real-time awareness of CVEs. They'll happily suggest a pattern that uses a vulnerable library version because that's what appeared most frequently in their training data. This is something we think about constantly when configuring Cloudflare or reviewing cloud security posture for clients: the threat surface isn't shrinking, and AI-generated code is adding new blind spots.

Where this is heading

Apple will probably formalize a clearer policy for vibe-coding apps eventually. The current case-by-case approach isn't sustainable, and the inconsistency, where one app gets pulled while near-identical ones stay up, will invite legal challenges.

But I don't think Apple is going to open the door to unrestricted on-device code execution. The App Review process is one of the few things that still differentiates iOS as a platform. Whether you love it or hate it, that review layer is partly why enterprise clients trust iOS for sensitive applications. In our work with healthcare and IoT apps, that trust matters.

The more interesting question is what happens on the web, where there's no gatekeeper. Vibe-coded web apps face no App Review equivalent. The quality and security gates are entirely up to the development team. For companies hiring agencies or freelancers to build web apps with AI tools, the diligence burden falls on you.

If that challenge sounds familiar, whether it's dealing with App Store policy for a native app or making sure your development pipeline can handle the pace of AI-assisted coding, let's talk. We've been in the trenches with this stuff across web, mobile, and security for a while now, and the conversation is always worth having.