The Anything Precedent: What Apple Actually Did

On March 30, 2026, Apple removed Anything from the App Store. If you've followed tech news lately, you've probably seen the headlines framing this as a "crackdown on vibe coding"—the emerging practice of building and publishing applications using natural language prompts rather than traditional source code. The reality is messier, and that's where the signal gets lost in the noise.

Dhruv Amin, Anything's co-founder, told reporters that Apple cited Guideline 2.5.2: apps can't download, install, or execute code. Fair enough on its face. Anything had raised $11 million at a $100 million valuation in September 2025, and by November, it shipped an iOS client that let users generate full applications through conversational interfaces. By March 2026, users had published thousands of applications through the platform. Then the door slammed.

Here's where I see the signal-to-noise ratio breaking down: Apple didn't announce a new rule. The company said it was enforcing an existing one. That distinction matters enormously for how we forecast whether this crackdown survives the year. If Apple had issued a blanket "no AI-generated code on iOS" mandate, we'd be watching a policy battle. Instead, we're watching interpretation enforcement, which is far stickier in regulatory terms and far harder to overturn via legal challenge.

Amin submitted a browser-preview workaround—basically, running code in a sandboxed web context rather than native execution—and Apple rejected it. Then Apple pulled the app entirely. That escalation tells us something: Apple isn't negotiating.

The Precedent Spread: Vibecode and Replit

Anything didn't exist in a vacuum. On March 18, 2026—twelve days earlier—Apple blocked updates to Vibecode and Replit, two platforms with longer track records and more embedded user bases. Vibecode had been on the App Store for eighteen months. Replit's iOS offering, while newer, had attracted serious developer interest.

Apple's justification was consistent: existing guidelines. No new rule. Just enforcement that, until 2026, had been dormant or selective.

This is where the system architecture becomes interesting. Apple's App Store review process doesn't work like legislation. There's no public registry of policy changes. Instead, enforcement happens case-by-case, precedent-by-precedent, often retroactively. From an information-theory perspective, that's the worst possible system for developer planning, but it's also the hardest system for regulators to challenge, because Apple can always point to the document—Guideline 2.5.2—and say, "We didn't change anything."

I want to be clear about my bias here: I think that lack of transparency is bad for the ecosystem. But it's also smart strategy for Apple's lawyers.

The DMA Complication: Timing and Teeth

Now, the DMA—the EU's Digital Markets Act—wrapped up its initial enforcement review in March 2026, the same month Apple started pulling apps. That timing isn't coincidental. The EU found Apple in violation of DMA rules on several grounds, including restrictions on alternative app distribution mechanisms.

The DMA gives the EU actual enforcement power: fines up to 10% of global revenue for violations, plus forced policy changes. Apple's annual revenue is roughly $400 billion. Do the math.

Here's the feedback loop I'm watching: Apple enforces Guideline 2.5.2 harder. Developers complain to EU regulators. EU says this looks like gatekeeping. Apple says it's just security. Regulators issue a directive. Apple either complies or fights—and the cost of fighting is existential.

The 60% probability estimate assumes Apple can hold the line through December 2026 despite regulatory pressure. That means either (a) the EU doesn't issue direct orders to reverse the vibe coding restrictions, or (b) Apple negotiates a middle ground that technically complies with DMA while maintaining most restrictions, or (c) this drags into 2027 and doesn't "resolve" in 2026 as we've defined it.

Why Apple Banned Vibe Coding: The Security Signal

Let's interrogate the stated rationale. Guideline 2.5.2 exists because Apple wants to prevent arbitrary code execution on its platform. That's a legitimate security concern, not corporate theatre. If every iOS app could download and run untrusted code, the security model collapses. The entire App Store review process becomes theater.

Vibe coding platforms like Anything do, in fact, enable something close to arbitrary code execution—users write prompts, the platform generates source code, and that code runs on the device. From Apple's perspective, that's a category error: it's not really an "app" in the traditional sense. It's a code interpreter with a natural language interface.

But here's the feedback loop I find myself caught in: the same argument could be made about JavaScript engines in web browsers, or Python runtime environments, or any Turing-complete system. Drawing a line between "safe" code (submitted to the App Store, reviewed by humans) and "unsafe" code (generated at runtime) is a policy choice, not a technical inevitability.

Speaking of which, the entire category of developer tools—IDEs, debuggers, compilers—operates on the principle that developers need runtime code generation. Apple's own Xcode is built on that premise. So when Apple enforces 2.5.2 against Anything but doesn't enforce it against development frameworks, we're not seeing neutral policy. We're seeing gatekeeping dressed up as security.

Platform Economics: The Real Pressure

Vibe coding platforms are existential threats to Apple's developer moat. Here's why that matters for probability estimation.

Today, if you want to build an iOS app, you need iOS expertise. You need to understand Swift, or Objective-C, or at least be willing to hire someone who does. That creates friction. It creates a high barrier to entry. It creates a market where skilled iOS developers command premium salaries, and Apple sits at the intersection of all those developers and all the money chasing iOS distribution.

Vibe coding disrupts that. If you can describe an app in English and have it automatically compiled to iOS, you've just removed the expertise barrier. You've democratized app development. You've also tanked the premium on iOS-specific knowledge.

From Apple's perspective, that's not a feature. That's a category threat. The company doesn't ban vibe coding apps because of security concerns. The company bans them because they're economically destabilizing to Apple's developer economics.

I said earlier that Apple enforces rules neutrally, but that's not true—that's the contradiction I need to sit with. Apple has always played hardball with platforms that threaten its margins. The company's history is littered with SDK restrictions that disappeared once the threat was neutralized, then reappeared when the threat returned. We should expect the same here.

Developer Sentiment: The Fractured Response

Here's where it gets interesting from a systems perspective. Developer sentiment isn't monolithic, and that fragmentation shapes how much political pressure Apple faces.

Enterprise developers—those building for large companies, financial institutions, healthcare systems—tend to support Apple's restrictions. They see vibe coding as a security liability. If your app is handling payment data or protected health information, the last thing you want is auto-generated code you didn't write.

Indie creators and bootstrapped founders? They're furious. Vibe coding represented a path to iOS distribution without expensive hiring. It meant solo founders could compete with teams. It meant faster iteration and lower barriers to experimentation.

That split matters. Enterprise developers have fewer alternatives; they need the iOS ecosystem. Indie developers have more mobility; they can move to web, Android, or other platforms. Apple cares more about retaining enterprise developers, which means the political cost of the crackdown is concentrated among groups with lower switching costs.

In systems terms, Apple is trading developer coalition unity for enterprise retention. That's a coherent strategy, but it's also a vulnerability. Regulators notice coalition fractures.

The Regulatory Playbook: What the DMA Actually Changes

The DMA enforcement in March 2026 wasn't specifically about vibe coding. It was broader: Apple can't arbitrarily restrict app categories, can't impose unreasonable approval burdens, can't enforce rules selectively to benefit first-party apps.

The vibe coding crackdown tests those boundaries. If a EU regulator looks at the evidence and concludes that Apple is enforcing 2.5.2 selectively—more aggressively against code-generation platforms than against other categories—that's actionable. It's evidence of anti-competitive gatekeeping, not neutral safety enforcement.

Apple's lawyers know this. That's probably why the company didn't announce a new rule. By enforcing an existing rule, Apple can claim consistency and neutrality. The harder case for regulators is proving that historical enforcement was selective.

That's a winnable strategy for Apple in court. But in regulatory proceedings, it's weaker. The DMA doesn't require proof of intent; it requires proof that the effect is exclusionary. Apple's enforcement has an exclusionary effect on vibe coding platforms. That's enough.

Scenarios: Three Paths Through December 2026

Let's build out the scenario space. How does this actually resolve?

<b>Scenario 1: Apple Holds (60% probability)</b>

Apple successfully negotiates with EU regulators, or the DMA enforcement process stretches past December. Apple doesn't reverse the vibe coding restrictions. Developers grumble but don't migrate en masse. Android gets a temporary advantage but doesn't seize significant iOS market share. This is the base case: regulatory cost stays below the value of maintaining platform control.

<b>Scenario 2: EU Forces a Reversal (25% probability)</b>

The DMA enforcement team issues a direct order: Apple must allow code-generation platforms or face escalating fines. Apple capitulates because the regulatory cost exceeds the value of the crackdown. Anything returns to the App Store. Vibe coding becomes a standard iOS capability. This scenario requires aggressive EU enforcement and Apple's conclusion that compliance is cheaper than litigation.

<b>Scenario 3: Muddled Middle Ground (15% probability)</b>

Apple and EU agree to a framework: vibe coding is allowed but subject to enhanced review, sandboxing, or restrictions on certain capabilities (e.g., no access to payment APIs, camera, or contacts). Anything returns but hobbled. Developers partially satisfied. Regulatory pressure subsides. Neither side claims victory.

The 60% base case assumes Scenarios 1 and 3 together. Our confidence interval (45%-75%) reflects uncertainty about EU aggressiveness and Apple's regulatory cost tolerance.

Methodology: PRISM Framework Applied

The PRISM model breaks the forecast into components:

<b>Regulatory Pressure (30% weight):</b> How likely is the EU to force Apple's hand? Current data: enforcement is active, fines are real, but bureaucratic speed is glacial. Medium-high pressure, low velocity. Estimate: 50% likelihood of direct intervention by Dec 31.

<b>Platform Economics (25% weight):</b> How much is this worth to Apple? Vibe coding is a category threat but not a revenue threat—the market is months old. Apple's enterprise revenue is stable. The economic incentive to maintain restrictions is real but not desperate. Estimate: 65% likelihood Apple maintains restrictions for economic reasons.

<b>Developer Ecosystem Response (25% weight):</b> How much will developers matter? Split sentiment means limited coalition pressure. Migration to Android is possible but expensive. Regulatory complaint mechanisms are slow. Estimate: 55% likelihood that developer pressure remains sub-threshold.

<b>Legal Precedent (20% weight):</b> Does case law favor Apple or regulators? The EU has been aggressive. The US has been deferential. Global variance is high. Estimate: 50% likelihood that precedent shifts against Apple's position.

Weighted: (0.50 x 0.30) + (0.65 x 0.25) + (0.55 x 0.25) + (0.50 x 0.20) = 0.15 + 0.16 + 0.14 + 0.10 = 0.55. Call it 60% accounting for Apple's historical ability to out-lawyer regulators.

Full Disclosure: Why This Estimate Might Be Wrong

I've been assuming Apple can successfully obscure enforcement selectivity by pointing to existing rules. But that assumption might be too generous. The DMA is explicitly designed to catch this move—the EU can examine Apple's enforcement history and determine whether rules are applied equally. The more I look at the evidence, the more I think Apple's legal strategy (enforce existing rules selectively) is actually weaker than I initially estimated.

If I'm wrong, the forecast should be 45% instead of 60%. My confidence interval accounts for this self-doubt.

FAQ

<b>Q: Is vibe coding actually a security threat, or is this purely about economics?</b>

Both. Vibe coding does introduce real security concerns (unreviewed generated code), but those concerns are manageable through sandboxing. The ban is economically motivated with security rationale. Apple's past behavior suggests it would tolerate the security risk if the economics were favorable.

<b>Q: Could Apple split the difference—allow vibe coding but with restricted API access?</b>

Yes, and that's Scenario 3. More likely than full reversal, less likely than the status quo. Probably 20-25% odds.

<b>Q: What's the timeline for EU enforcement?</b>

Directives typically take 3-6 months after DMA violation findings. Fines take longer. By year-end, we might see a preliminary order, not a final ruling.

<b>Q: Could vibe coding become standard on Android faster than iOS?</b>

Absolutely. Google hasn't announced restrictions. Android market share is larger globally. If Apple holds the line, expect major growth in Android-first vibe coding apps by Q4 2026.

<b>Q: What's the precedent for Apple reversing app-category bans?</b>

Limited. Apple rarely reverses bans. It prefers to redefine categories or claim the threat is neutralized. That pattern suggests a lower probability of Scenario 2 (EU forces reversal), which is why it's only 25%.

Open Questions: What Actually Matters

The resolution of this forecast hinges on one question: What does Apple's enforcement history look like when regulators examine it closely?

If Apple has enforced 2.5.2 evenly across different app categories for the past five years, the crackdown survives. Apple can claim neutrality. If enforcement has been selective—aggressive against code-generation platforms but lenient toward native apps with similar capabilities—regulators have ammunition.

We won't know the answer until regulators actually look. And regulators move slow. That's why the December 31 resolution date exists: it's just barely enough time for the EU to issue a directive if they move aggressively, but not enough time for litigation to conclude.

The model says Apple maintains restrictions through 2026 at 60% probability. But my gut says the probability is lower, maybe 50%. The EU doesn't appear to be in a patient mood, and Apple's strategy (enforce existing rules selectively) looks increasingly fragile under regulatory scrutiny. The company might hold through December, but I'd be surprised if it holds into 2027.