· 7 min read

Apple Booted Anything From the App Store Twice — Vibe Coding Just Met Its First Real Gatekeeper

Tools Lessons Building in Public

Apple Booted Anything From the App Store Twice — Vibe Coding Just Met Its First Real Gatekeeper

Anything was one of the most-hyped apps of Q1 2026. Open the app on your iPhone, describe what you want in plain English, and the app generates a working mobile app for you — on your phone, from your phone, for you and your friends to use. The vibe-coding movement on consumer hardware, basically.

Apple removed it from the App Store on March 26. Restored it on April 3 after pushback. Removed it again almost immediately — this time on a different rule, that Anything couldn't market itself as an "app maker" at all. On April 14, co-founder Dhruv Amin went public with the whole timeline and their response plan. The plan, in short: pivot to a desktop companion that lets users build apps for iOS from a Mac, keep an iMessage version alive, and stop trying to ship user-generated code inside the iOS container.

This is the first big, clean test of what happens when the vibe-coding wave meets the iOS gatekeeper, and the gatekeeper won decisively. Anything isn't alone — Replit and Vibecode got their updates paused in the same crackdown. Apple's stated reason is a rule that's been sitting in the App Store guidelines since late 2025, prohibiting apps from "changing code or operating outside their bounds after App Review is complete."

For any solo operator with an idea in this space, a few things are now settled. And a few things are now interesting in different ways than they were a month ago.

The Rule Apple Is Actually Enforcing

Let's be accurate about what the guideline says, because this matters.

Apple's position isn't "vibe coding is bad." It's "apps cannot ship code paths that weren't reviewed by App Review." That rule predates the vibe-coding wave. It's the same rule that's kept JavaScript-heavy webview apps in a gray zone for a decade, the same rule that kept gaming emulators out for fifteen years, the same rule that made every iOS-based scripting environment weird to ship.

What changed in 2026 is that vibe-coding apps cross that line more visibly than anything before them. The whole point of Anything is that user-generated code becomes the user's app. Apple's App Review cannot audit code that doesn't exist at review time. So either Apple enforces the rule against these apps or Apple quietly admits the rule never really mattered.

They chose enforcement. That's rational from Apple's perspective even if it's frustrating from ours.

App Store submissions surged 84% in Q1 2026, almost entirely on the back of vibe coding, and Apple clearly looked at that curve and decided the App Review bar couldn't be crossed at that scale without breaking the whole model. Whether you think Apple's model is too restrictive is a separate conversation. In the world as it actually exists, the rule is being applied now, and it's going to keep being applied.

The Security Story That Makes This Harder to Argue With

Here's the part I can't wave away, even though I want to.

In early April, a security firm ran scans across 15 randomly sampled vibe-coded apps shipped to the App Store and found 69 distinct vulnerabilities. Independent research puts the security-flaw rate of AI-generated code somewhere around 80%. Some of those are trivial. Some are actual "this will leak your users' data" flaws. All of them are the kind of thing App Review is theoretically supposed to catch.

If you accept that Apple's job is to keep iOS users reasonably safe on the platform, and you also accept that roughly 4-in-5 AI-generated apps have exploitable bugs, then the policy isn't really about protecting Apple's cut. It's about a real threat model that vibe-coded apps make measurably worse.

That doesn't mean Apple's enforcement is graceful or fair. The specific way they pulled Anything — first citing malicious-code concerns, then flipping to marketing-language objections when the first claim didn't hold — is the kind of inconsistency that makes developers feel gaslit. You can think Apple's concern is valid and also think the way they're implementing it is bad. Both are true.

What's Dead, What's Not

A few things are clearly dead as indie mobile strategies in 2026, and it's worth being explicit:

Shipping a consumer iOS app that generates new iOS apps is dead. Not "hard," not "risky." Dead. Anything tried three ways in two months and got rejected. If you're planning to build this, stop.

Shipping user-downloadable code payloads on iOS is dead. Webviews that execute significant new JS from a server, plugin systems that pull fresh code, any flavor of "user extends the app with code that wasn't reviewed" — all landing in the same enforcement bucket. Some of it may still slip through; none of it is a defensible long-term strategy.

Marketing your indie app as an "app maker" is risky even if the underlying functionality is fine. Anything's second removal was reportedly tied to marketing language, not the app itself. Apple is now policing the pitch, not just the binary.

A few things are very much still alive, and interestingly so:

Desktop companion apps that generate iOS apps are fine. Anything's pivot is instructive. Build on Mac (or Windows, or web), deploy through standard iOS channels. The user pays the toll once, at compile time, where Apple can actually review the output. This is a worse UX than "build apps on your phone," but it's a real UX, and it's permitted.

Web-first vibe coding is better than ever. PWAs, browser-based tools, Astro on Vercel today and Cloudflare or DigitalOcean tomorrow — the boring, portable stacks we keep coming back to. The iOS App Store was never the friendliest venue for indies, and the friction just got steeper, which makes the web even more attractive in relative terms.

Server-side code execution with a thin iOS client is also fine. The classic "chat app where the smart stuff happens on your server" pattern isn't affected by any of this. That's how most successful AI apps on iOS are already structured, and it's the path of least regulatory resistance.

The Honest Solo-Operator Read

Here's what I'm taking away, as someone who's been tempted by the vibe-coding-on-phones idea more than once this year.

The iOS App Store has always had a ceiling on what indies can build, and it's always been more about "what Apple will allow" than about "what's technically possible." For a brief moment in late 2025, it felt like AI code generation might let us route around that ceiling. That was a nice dream. It's over.

What replaces it isn't worse, but it is less glamorous. Web distribution. Desktop-first tooling. iOS as a thin client to cloud-side smarts. Boring, battle-tested paths that survive Apple's enforcement because they don't try to route around it.

If you're a solo operator, the right move isn't to be mad at Apple. Apple is going to keep being Apple. The right move is to plan your roadmap like Apple's enforcement is the weather — real, unfair at the edges, and not going to change for you. Build for the weather.

Anything's pivot to a desktop version is the correct move, not a sad one. It's the indie playbook reasserting itself after a brief detour: build where the gatekeepers aren't, serve the users they can't reach, and stop arguing with the ones that hold the keys to the mall.

Sources

More Tools articles →

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Related Posts