Apple is rejecting useless apps: the answer is not to spend weeks on them
· 6 min read
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:
“Don't submit apps that are indistinguishable from others already widely available. Opportunistically creating variations of existing categories or popular apps degrades App Store discovery, reduces overall quality, and harms both users and developers.”
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:
“We may remove these apps from the App Store in the future if they are not updated, improved, or if they fail to attract customers. Repeated submissions of this kind can lead to removal from the Apple Developer Program.”
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.
A grocery list app in a crowded category
I shipped one this year, and on paper it is the kind of app these rules are aimed at. Grocery lists are crowded. Apple's own examples name flashlights, wallpapers and basic timers, and a shopping list lives close enough to that street to make you think twice before building another one.
It passed App Review the first time it was reviewed, with no rejection and no exchange with a reviewer.
It passed because it does one thing nothing else on the store does the same way. TapTap Grocery is one screen and one tap. You tap a big coloured icon and the item is on the list. There is no search field, no recipe library, no pantry inventory, no barcode scanner, no meal planner. A child who cannot read yet can add apples, because the picture is an apple. It runs on Apple Watch, which is where a list belongs when both your hands are full.
The features I left out are the whole argument. Grocery apps grow recipes and weekly menus because that is what you reach for when you need a reason to charge more. Every addition costs a tap, a screen, or a decision, at the exact moment someone is standing in a kitchen with a child pulling at their sleeve. Leaving them out was not laziness. It is the product.
That is what a genuinely different experience means in practice. It does not require a new category, and it does not mean out-featuring the incumbents. It means having a defensible answer to the question review is really asking: why does this exist when the others already do? Here the answer is that the others are not one tap and one screen, and cannot become that, because of everything they chose to add.
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.