Apple is rejecting low-effort apps. That is good news if you build real ones.Apple is rejecting low-effort apps. That is good news if you build real ones.

Apple updated the App Store Review Guidelines in June to say it will not approve apps in several named categories - dating, flashlight, sound effects, wallpaper, simple timers, fortune telling - unless they are meaningfully different from what already exists. Reporting listed fart, burp and drinking game apps among those described as low-effort.

The instinct is to read this as housekeeping aimed at other people. It is worth reading more carefully than that.

Meaningfully different is doing a lot of work

The operative phrase is not the category list. It is the standard applied to it, and that standard is a judgement call made by a reviewer you cannot talk to in advance.

For a studio this shifts risk into an unfamiliar place. Technical risk you can estimate. Schedule risk you can buffer. A subjective approval decision made after the build is complete is a different animal, because the cost of being wrong is the whole project rather than a slipped week.

It is also risk that arrives at the worst point in the project. Technical problems surface while there is still budget and appetite to respond to them. An approval judgement lands when the app is finished, the invoice is mostly raised and the client has already told people it is coming.

The categories are the visible part

Reading the list as a list is the mistake. What it describes is a class of app: one whose entire function is available in dozens of near-identical products, where the only differentiation is the icon and the listing.

That class is larger than the six names in it, and the named categories are examples rather than boundaries. A product does not need to be a flashlight to be indistinguishable from what already exists.

The useful question is not is my category on the list. It is what can this app do that the twenty nearest results cannot, and would a stranger see it in the first thirty seconds. If the honest answer is nothing much, the category is irrelevant.

What we changed in how we scope

• If a product sits near a named category, that is raised in the first conversation, not discovered at submission.
• For anything borderline, we build the differentiating feature first rather than last - so if it turns out to be thin, that is visible in week three rather than month four.
• Submissions go in earlier, with a real buffer for a rejection-and-appeal cycle.

None of this is defensive paperwork. It is the same discipline that makes for a better product: if you cannot articulate what makes the app different in one sentence, the reviewer is not the only person who will struggle with it.

Building the differentiator first is the item that changes projects. The conventional order puts the distinctive feature last, after login and settings and the list view, which means the riskiest assumption in the whole project is tested when the money is spent. Reversing that is uncomfortable to schedule and occasionally ends a project early, which is the point of it.

The conversation to have with a client

This is not a comfortable subject to raise in a first meeting, and raising it anyway is part of the job.

The framing that works is not you might get rejected. It is this app needs a reason to exist that a stranger can see, and here is the test it will be held to. Clients rarely argue with that, because it is the same standard their customers will apply. The ones who do argue have usually told you something important about the project.

The bad version of this conversation is silence followed by a rejection, at which point the studio is explaining a risk it knew about and did not mention.

Why the direction is right

It is easy to be cynical about a platform owner tightening discretionary control. But the practical effect of a store full of near-identical utilities is that genuine products compete for attention with noise, and users learn to distrust search results.

A store nobody trusts is worth less to the people building real things in it.

If your app does something specific for a specific person, this is a change in your favour. If it does not, the guidelines are telling you something the market was going to tell you anyway, just more expensively.

The reasonable worry is the one about discretion rather than intent. A rule enforced by judgement is applied unevenly, and a small developer has less recourse than a large one. That is a real cost and it is worth naming. It does not change the practical advice, which is to be the kind of app the rule was not written for.