At some point, your app will be rejected
There, we said it… if you’re actively developing apps for a centralized app marketplace (like the iTunes App Store, Mac App Store, Android Market, Windows Phone 7 Marketplace or Blackberry App World), it’s almost a certainty that at some point in your development life one of your apps will be rejected. Trust us, we’ve seen enough examples of this to know that at this point, app store rejection is like a badge of honor to prove that you’re an active developer. With a ton of editorial leeway and human decision-making involved, app store submission reviews are capricious in nature.
Android and Windows Phone 7 appear to be a bit more lenient, but we’ve heard plenty of rejection stories from those markets as well, so it’s not enough to say, “Apple’s restrictive and the rest are wide open”. Since we talk with a lot of developers and are very focused on helping them be as successful as possible we keep close tabs on what best practices are and where developers would be wise to spend a little more time being cautious in their development.
Some generic guidelines we’ve come to understand through our work with developers:
- Don’t use Apple’s name in vain
- Don’t use private APIs
- Avoid making the platform look bad
- Demo apps and those without “minimum user functionality”
- Avoid copying core functionality of the OS’s pre-installed apps
- Be careful with language and user-generated content
- No porn (unless you’re on Android, but even then, you need to use a 3rd party adult app market)
In addition to our list, we’ve come across many other takes on rejection and best practices. Here are a few of the best:
- 10base-t’s take on rejection criteria
- This Tumblog is fun to peruse for app rejection reasons
- A slightly dated but well-written guide