Apple is rejecting useless apps: the answer is not to spend weeks on them

On June 9, 2026, Apple tightened its review rules to weed out apps with no value. Many read a simple message into it: from now on you have to spend weeks on an app for it to be accepted. That is wrong. Apple does not measure the time you put in. It looks at whether the app deserves to exist.

What Apple changed on June 9, 2026

The main change hits guideline 4.3(b). Apple adds one unambiguous sentence:

Apple even names the categories that will no longer be accepted without a genuinely different experience: dating, flashlight, sound effects, wallpapers, basic timers, fortune telling. It files fart-noise, burp, Kama Sutra and drinking-game apps under “mediocre, low quality, or low effort.”

The test is not the time you spent

This is the point most of the commentary misses. Apple does not reject an app because it was made fast. It rejects it because it adds nothing. One more clone gets bounced even if it cost you three weeks. A focused app, with a real reason to exist, built in four days, passes.

So value is not a question of hours. You can spend a month polishing an idea nobody cares about, or ship in a few days something that solves a real problem. Apple wants to see the second one.

The clause that really changes the game

The most important part of the crackdown is not the rejection at the door, it is what happens afterward. Apple now reserves the right to pull already published apps:

So an app can be accepted, stay live, then vanish for lack of users. And a developer who churns out pointless apps risks the account itself. Spending six weeks polishing an app in a vacuum, never putting it in front of real users, becomes the worst possible bet.

Why an MVP in a few days is the right answer

If Apple rewards usefulness and real usage, the logic is to ship a version fast that does one thing well, put it in real users' hands, then iterate. Not to polish it for weeks before you even know anyone wants it.

A good MVP rests on a clear core:

• One main feature that actually works, not a mockup
• Real native features, the kind a plain website wrapped in a webview cannot offer
• A clean settings screen, with privacy and notification controls
• Enough measurement to see whether people come back, so you can decide what to build next

That core comes together in a few days when you know where you're going. The rest, the secondary features and the edge cases, comes later, once the app has proven someone cares.

Fast because experienced, not fast because rushed

There is a distinction worth keeping. “Ship in a few days” is not the same as “cut corners.” The apps Apple is purging right now are exactly the ones produced fast and without craft, often generated by vibe coding tools. Speed does not save them, their lack of value sinks them.

The difference comes down to experience. After eighteen years building apps, you know what passes review and what gets bounced. You know which native features a reviewer expects, where guideline 4.2 trips people up, why a disguised web app never lasts. You don't waste time rediscovering these rules by collecting rejections. You build the app right the first time.

That is what shipping fast without shipping badly means. You cut the waste, not the essential features. The core is never up for negotiation. What you drop is the weeks spent polishing what nobody needs.