Apple, like Google, was naive once, hoping that developers would respect their customers as much as they do (unless you're big enough that kicking you out of the app store would make their products less marketable).

They got proven wrong, and had to invent policy after policy to try to fix things. Google has been restricting permissions while Apple has gone even further.

Most developers don't need all that much special treatment. Picking between three codes in a few categories isn't really that much work. At least they don't require you to manually email the app reviewers!

This stuff only seems to be a major issue for developers trying to use APIs in way Apple does not allow them to be used.

> Picking between three codes in a few categories isn't really that much work.

True, but it's not just that. These changes are just another item to add to the already very long checklist.

I'd much rather they add to the App Store ToS "I will not use the following APIs/syscalls for fingerprinting users: [stat, UserDefaults, etc...]" rather than all this busywork. Since these restrictions are enforced by the review team (vs. the OS), the end result is the same.

I would imagine that a description of what the api is being used for makes life way easier for the review team to check whether you are telling the truth.

I think apple noticed a long time ago that the world is not exactly lacking in quantity of phone apps. If anything, the sheer number of them has become a hindrance to anyone wading through thousands of nearly identical apps to try to find the actually good one.

So if they implement policies that increase the average quality of apps and decrease the total quantity, that's an improvement for users twice over.