Halide Rejected From the App Store
The latest Halide update was rejected because, after seven years, a random reviewer decided our permission prompt wasn’t descriptive enough.
I don’t know how to explain why a camera app needs camera permissions.
If you think the reviewer was correct because “The camera will be used to take photographs” is a circular description, note that:
It took the better part of a decade for Apple to catch this.
ProCamera’s description is “Usage of the camera is needed to take photos and videos.”
Final Cut Camera’s description is “Allow camera access to record video.”
Halide may have been featured during the iPhone 16 keynote, but it seems that wasn’t enough to protect it from an over-zealous App Store reviewer.
[…]
Halide’s Sebastiaan de Wish says the company received a call from Apple informing them that this was a mistake.
Do they do any postmortems for these erroneous rejections? Why isn’t there some sort of warning to the reviewer: did you really mean to reject this app for metadata that was already accepted 100 times in a row and hasn’t changed?
Apple followed up to let us know what happened. Normally they don’t do this for camera apps, when it’s obvious why the camera is used.
So the goof was that the reviewer didn’t know it was a camera app?
My image editing app got rejected because Apple didn’t know why an image editing app needed access to photos to edit their photos…
Previously:
Update (2024-09-25): Francisco Tolmasky:
The actual funny thing about this is that while some AppStore reviewer is complaining about the camera prompt in Halide, I’m fairly certain that literally no users understand what the fuck allowing an app to “find and connect to other devices on the network” does.
10 Comments RSS · Twitter · Mastodon
It's a common refrain, but remember when the App Store was new and Steve et all warned that "running to the press won't solve any problems"? But in fact it seems like the only way!
Not sure there is a point in doing a postmortem.
Everyone knows that AppStore reviewers do not need to be Nobel Prize materials. And that their managers are probably pushing them to review more apps every day (and are probably not geniuses either). So there are no reasons to be surprised by the repetition of stories like this one and nothing can really prevent this from happening again and again.
This should be seen as a good thing instead that a well-known 3rd party developer is getting the same bad quality reviews as other less known developers. Apple always says that all developers are equal.
Definitely agree with @someone – initially this could be seen as a net positive for developers as it shows that even if you are one of the Apple anointed developers who get to appear in their keynotes and get a ton of positive exposure you will still be treated like a peon when it comes to App review.
However, then we hear that, no, not everyone is treated equally. Certain developers get personalised phone calls with an apology when a common App review mistake is made.
I'd prefer that everyone gets treated equally poorly, then perhaps some real change can occur.
My experience with Apple's iBooks Store reviewers was that English as a first language, or even English as a *fluent* language wasn't a requirement for reviewers.
Combined with time constraints, I honestly think that's a big part of the problem. In my case I had an update with the phrase "...to correct an artefact caused by the way iBooks renders...", and the reviewer's note was "don't refer to your publications as "iBooks"", and the only response I could give was "no, I'm referring to iBooks, the app, by it's proper name" - and there's 48+ hours wasted on my launch window.
I stopped using the platform because of these software border checks. It’s death to ownership by a hundred cuts.
Someone new at the (low paying)job followed the instructions they were given. This is the system working as intended.
I find often these rejection outrages are total overreactions, most of the time a rejection is just a request for clarification. Sometimes mistakes happen, sometimes there are new employees. I think it's great that older more prestigious apps are treated in the same way as everyone else. At the end of the day, maybe it's just a question of karma.
Well it's no big deal in this case being that this was an *obvious* mistake and was quickly corrected. However, lesser known devs have had app updates held up for weeks with lengthy back-and-forths with App Review and continuous rejections for nonsensical reasons. Been there.
And when these reviewers tell you what to do in order to get in compliance...they can lead you down a rabbit hole because some of them don't know what they're doing. Sometimes these mistakes are costly (weeks of unnecessary work).
I think Apple can afford to improve the training requirements for reviewers. In the case of iOS where there are zillions of submissions daily, if scaling this is "not feasible" they shouldn't be able to have it both ways. If App review is necessary for "safety" then the reviewers need to be qualified. Otherwise allow sideloading.
It may be confusing to some that the very same people who decide that the prompt "The camera will be used to take photographs" is dangerously unclear are also able to divine whether an app will hack your iPhone. The key to this mystery is that language comprehension skills and oracular skills are quite orthogonal. Indeed, our men (and women) who stare at goats are the best in the industry.
Trust our expertise to protect you from malevolent 3rd party app developers. We rarely divulge our secret know-how, but in this case we'll show you how we do it, so that you can rest certain that our methods are totally sound: Application developers, whose name their product after a class of chemicals used in Chemical Weapons, Pesticides, Herbicides, and illegal drug manufacturing, can hardly be trusted with (y)our precious devices.
