Back when the iPhone 4 came out I created a nice little flashlight app, as I expected it would be a popular utility and a pretty easy one to create.
I didn’t own an iPhone 4 though, so I had to send ad hoc builds to a friend of mine to test if it was actually activating the light properly. It was mostly working, but had problems with multitasking which I was not able to fix without an actual device in hand.
As often happens, other projects took priority and the flashlight app fell by the wayside…until a couple of weeks ago when I bought my iPhone 4S.
I trotted out the flashlight app to see if I could make it work. After an hour or so, not only was I able to make it work and deal with multitasking properly, but when I tested it against all other flashlight apps that make the claim of “fastest time to light on”, mine was twice as fast as most of them. I thought “Hey, I can put this in the store now and make the claim of being the “REAL” fastest flashlight in the App Store!
So I polished up the graphics and after a bit more testing I submitted it to the App Store for approval.
Rejected!
Those of you who have kept up with the nitty gritty details of the terms of the Apple developer agreement will know that I was quickly greeted with a rejection email from the app review team at Apple.
According to section 2.11 of the agreement:
2.11 Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them, such as fart, burp, flashlight, and Kama Sutra apps
Hmmmm…didn’t see that coming. Flashlight apps are specifically mentioned! Guess I need to read the developer agreement in detail again. I’m willing to accept that responsibility.
It is, however, the “such as” part of the sentence is rather worrying. It means that this list is not definitive. A new category of app could be added to the list at any time or worse yet, it might depend on one reviewer’s opinion.
What’s next? Compass apps? Calculator apps? Tower defence games? Who knows? Maybe the app that you are working on right now will be banned tomorrow!
The reply from the reviewer continued:
We recognize that there is a wide range in the quality of flashlight apps and that yours may be of better quality than many others out there. Or, it may include features or characteristics that distinguish it as more than just a flashlight app – or even something other than a flashlight app. But if a feature or set of features in your app primarily provides flashlight functionality in any form, in spite of other features or qualities it may also include, it fits the category of flashlight apps. And, at the end of the day, we simply have enough flashlight apps in the App Store.
Flashlights and fart apps aside, the above message effectively says that Apple doesn’t care if your app is the best example of a given category if, in their opinion, there are already “enough” of them in the App Store.
This has two important implications:
- Existing developers with high-performing apps in that category now effectively have a monopoly on it (OK, there is more than one of them, so maybe it’s an oligopoly…).
- Developers with ideas to improve apps in that category are forbidden from creating innovative new apps.
It seems Apple’s intent with this restriction is to try to keep the clutter out of the App Store, but this policy strikes me as one of the worst ways to achieve that goal.
A Better Way?
If one assumes that Apple’s desire is to curate the App Store in such a way as to ensure a steady flow of high quality apps, I think the following changes would achieve that goal in a much better way.
- Stop accepting poorly coded apps
I download apps quite frequently that fail to launch or crash almost instantly. Surely Apple’s review team can vet out these apps more effectively before turning them loose on the public. - Stop accepting apps with crappy graphics
Apps with low-quality “artwork” abound in the App Store. It’s not hard to tell the difference between an app with intentionally “doodle style” graphics and one where no effort has been put in whatsoever. - Stop accepting apps that use Comic Sans font
Seriously? Yes, seriously. There is a direct correlation between the use of Comic Sans and crappy apps. - If an app has not been downloaded or purchased in the last 60 days, automatically remove it from the App Store
Apps that are not being download are more likely to be shovelware. This is not always the case, but even developers whose expectations of being the next App Store Millionaire have been dashed usually sell several copies of their app or game every week, thus keeping them clear of this provision. - If an app maintains a 1 star rating for more than 60 days, automatically remove it from the App Store
This provision gives the public a voice to help clear out garbage from the App Store. If an app cannot maintain a rating of more than one star, it clearly has problems. This could indicate poor coding, bad art or just a poor overall design. In any case, the app is probably not worthy of being on the App Store. - Don’t place arbitrary limits on how many apps can exist in a given category
The previous provisions will go a long way to removing junk apps from the App Store, so there should be no need to artificially limit it in this way.
Some people may feel that automatically removing an app from the App Store is a rather drastic action, however, I feel it is both warranted and necessary to increase the quality of apps on the App Store.
Help! I’m Being Repressed!
If a developer’s app is automatically removed from the App Store, he/she has two options:
- Accept the removal and do nothing
If the app is not resubmitted 60 days after it has been removed from the App Store, then it will be removed from the system completely.
- Resubmit the app after making changes to it
The newly submitted version will need to be accompanied by an explanation from the developer on what has been changed to address the quality issues.
A Starting Point
As with any system, the above suggestions will raise new issues and would require further additions and qualifications, however, I think this is the direction in which the approval process should be moving.
I’d love to get further input on this topic. Do you agree with me? Do you have a better idea? Let me know in the comments.
