Lessons Learned From the App Store
Former App Store head Phillip Shoemaker:
A discussion about why App Stores have guidelines, how apps are reviewed, what reviewers are looking for, and what the common mistakes are. In this talk, I will give you tips and tricks necessary to avoid problems on the App Store and Google Play.
It boggles the mind that he was a developer who had submitted his own apps to the store.
See also: Peter Steinberger.
5 Comments RSS · Twitter
@someone He seems to understand a lot of the issues facing developers. So why did the App Store remain so unfriendly during his tenure? Was his team unable to execute? Where they blocked from higher up? Whose decision was it not to use the carrot?
I only skimmed this video, but I was at RWDevCon a few weeks ago, where Shoemaker gave essentially the same talk. It really sounded like in many ways, his hands were tied and he's slightly bitter about it now. Reading a bit between the lines, I got the impression that:
- His team was understaffed for much of its history.
- He was only responsible for the execution of app review policy, not for setting those policies. And it sounded like he often disagreed with and pushed back against certain policies.
- They were making it up as they went along when it came to unexpected novel uses of APIs and such (... which doesn't come as a revelation to anyone)
- There was something of a mandate that app reviewers be shrouded in secrecy.
My speculation is that the net effect of all this (only being able to spend a few minutes on any given app, hiding from public view the internal debates they were having regarding policies and their interpretations, and trying to preserve the anonymity of the reviews) led them to err on the side of making app review an opaque black box process.
@michael There are so many factors that contribute(s|d) to this. In addition to understaffed teams, based on dealing with the (Mac or iOS) App Review teams:
- they didn't have a lot of tools at the beginning to quickly make a technical review of the apps. I don't buy the idea that not having access to the source code prevents them from finding out whether an application behaves suspiciously. This is basically what malware analysis is all about for instance.
- there was/is technically incompetent staff members that don't have a clue what the automatic analysis tools are reporting. At the same time, it would make sense to hire technically incompetent people as reviewing apps would seem to be a chore and something that anyone can do. At first sight. And then comes the technically unforeseen (but yet obvious).
- there are/will be certain types of applications that they don't want on the store but are not willing to publicly admit that they don't want them. This can lead to some sterile discussions with the review board where the Apple side is lying on the reasons why a product has been removed or rejected from the store. They will quote some paragraphs from the guidelines that do not apply to the situation they are dealing with. Or the other explanation is that they are complete bozos.
- there was no point in using the carrot as the app submissions were exploding. Apple was more interested in the number of apps on the stores than the quality of the apps.
[…] Previously: Lessons Learned From the App Store. […]
What boggles my mind is not really the submission of apps. But the kind of apps he submitted. So the part in his presentation about him writing to Apple at the time to complain about the rejections is probably lacking some context regarding the apps.