Vibecoded Apps Are Forcing Apple to Explain What App Store Review Actually Checks

Apple is now facing a public version of a question every small developer already argues about at lunch: does a flood of AI-built apps help the App Store or wear it down. The New York Times raised that exact question this week, and it's worth sitting with, because the answer shapes what gets reviewed, ranked, and buried next to whatever we ship.

Quick facts

• "Vibecoded" describes apps built mainly by prompting an AI model rather than writing code line by line.
• The Times piece asks whether rising volume of such apps helps or hurts Apple's store.
• Apple's published review guidelines focus on what an app does and how it handles data, not how it was built.
• Apple does not publish review queue depth or monthly submission volume, so turnaround trends are not public.

"Vibecoded" is the term making rounds for software assembled by describing what you want to a model and accepting most of its output, rather than planning structure up front or checking every function by hand. The label carries a shrug in it, half compliment, half complaint, usually said by someone who didn't build the thing about someone who built it fast. For storefront purposes the term itself means nothing to Apple's rules — the guidelines ask about behavior and data handling, not typing method. That mismatch is the real friction the Times piece points to.

What counts as a "vibecoded" app?

There's no official definition, and Apple doesn't ask developers to disclose their process. What's changed is the ratio: more people can produce something that looks finished in a weekend, and that something enters the same queue as an app someone spent a year hand-writing. Review can't tell the difference by looking, and arguably shouldn't have to, since the rules were written around outcomes.

Why does Apple care about volume?

Every submission, regardless of who or what wrote it, moves through the same human and automated checks. A larger share of thin wrapper apps or near-duplicate utilities makes the signal-to-noise problem in search and category browsing worse before it gets better. A storefront where genuine finds are hard to surface starts to look less like a market and more like a pile with a search bar on top of it, which is a problem for Apple's own business, not just a policing headache.

How do shoppers tell quality from noise?

Mostly they don't, at least not fast. Star counts lag new releases by weeks. Screenshots can look polished regardless of what sits underneath them. Charts reward whatever gets installs quickest, which under a glut of similar utility apps tends to favor whoever spent the most getting noticed rather than whoever built the better tool. We've watched our own corner of the store fill with apps solving the same narrow problem in nearly identical ways, and telling them apart by browsing alone is close to impossible without already knowing what to look for.

Does review time stretch when submissions spike?

We don't have Apple's internal numbers here, and the Times piece doesn't cite them either — queue depth isn't something Apple publishes. What we can say from our own update submissions this year is that turnaround has stayed roughly where it's been, not visibly longer. Whether that holds as volume keeps climbing is the open question the article is really raising, not a settled fact yet.

Where do we fit into this as a small team?

We build narrow tools and write the code ourselves, which used to be unremarkable and now apparently reads as a selling point. That's a strange place to land. AI assistance already touches parts of how we build too — drafting, debugging, catching mistakes. The line we hold is that nothing ships until someone on our team understands every part of what it does, because that's the only way we can answer for it when something breaks or a reviewer has a question. Whether that distinction matters to shoppers, or just to us, is something the next year of App Store changes will answer better than we can right now.