Apple is rejecting vibe-coded apps. The signal is bigger than the App Store.

Apple has quietly started rejecting and removing a specific category of submissions from the App Store: apps built with vibe-coding tools — services where you generate a working product from a few text prompts, no real code involved. The Financial Times reported the pattern this week, and the trend matters more than any individual rejection.

The framing isn't anti-AI. Apple is citing the same review guidelines it has used for years — minimum quality, real functionality, no misleading users about what the app actually does. What changed is the volume of submissions failing those checks, and where they're coming from.

The App Store isn't the most interesting part of the story. The interesting part is what it tells you about shipping a product that was generated rather than engineered, on any platform with a reviewer at the door.

What App Review is actually doing

The rejections cluster around a handful of guideline numbers any regular submitter knows by heart. 4.2.1 covers apps that aren't functional or are essentially duplicates. 4.3 covers spam, including apps that copy a popular product with minor variations. 5.2 covers misleading users about what the software does. None of those rules are new. The volume of submissions tripping them is.

Apple hasn't published numbers. From what the FT pieced together, App Review is seeing waves of submissions that visibly fail the same checks in the same ways: UIs that look polished in screenshots and fall apart on first launch, 'AI' features that are one model call wrapped in a UI, listings that copy a popular app's name and icon with the product half-implemented. The reviewers don't have to look hard.

Why vibe-coded apps fail this review

Vibe-coding is excellent at the first eighty percent of a product. Login screen, list view, settings page, onboarding flow — the model has seen thousands of those, and it will scaffold one in minutes. Where it falls apart is the last twenty percent: the work nobody wants to spec out and the model has no reason to volunteer.

That last twenty percent is what a reviewer notices first. The keyboard covering the input field. The network call that hangs without a timeout. The empty state that ships with placeholder text. The permission the app requests but doesn't actually need, because the model copied it from a template that did.

A few patterns the rejections keep falling into:

• Thin wrappers around an LLM with no functionality of their own — the AI call is the product, and there isn't much else around it.
• Visual clones of popular apps where the underlying logic is half-finished or missing entirely.
• 'AI X' listings — AI photo editor, AI calendar, AI todo — where the AI part is one API call and the rest is broken.
• Cargo-culted permissions, entitlements, and SDK includes the developer doesn't actually need, because the model put them in by template.

None of these are new failure modes. App Review has caught the same things for fifteen years. What's new is how cheap they are to produce, which means a lot more of them show up at once, which means review gets stricter to compensate. The bar moves up because the floor came down.

The lesson is platform risk

Apple is the loud example because Apple controls the only meaningful distribution channel for iPhone software. The same dynamic exists everywhere there's a gatekeeper — Play Store, Chrome Web Store, GPT Store, Shopify's app marketplace, anywhere a product needs someone else's permission to reach users. Rules don't change often. When they do, they change for everyone in your category at once.

For anyone shipping AI-assisted software, the practical implication isn't to stop using these tools. It's to remember that 'I built this in a weekend' and 'this is a product that survives a review process' are two different claims, and to plan for the second one from the start.

In practice that means being specific about what the product does for the user — 'AI-powered' is a marketing word, not a value proposition. It means investing in the parts vibe-coding tools are weakest at, which are also the parts reviewers care most about. It means reading the relevant guidelines before submission, not after the rejection email shows up. And it means not betting the whole business on a single distribution channel, because eventually that channel will shift the rules.

AI-assisted development isn't slowing down. The bar to ship something is going to keep dropping. The bar to ship something that survives a review process — and a real user — is going the other way. Both can be true at once. That's the gap worth designing around.