Acing the App Store Approval, Part 1: Understanding the Nitty Gritty

linkedin Acing the App Store Approval, Part 1: Understanding the Nitty Gritty

app store badge transp Acing the App Store Approval, Part 1: Understanding the Nitty GrittySince the birth of the App Store four years ago, Apple’s App Review process has never stopped stirring discussions in developer forums. There are multiple reasons for that: a certain mystery around the approval policies, ambiguity and frequent changes, impact of the reviewer’s subjective opinion on the outcome of the approval, and Apple’s biased rejection of all applications that could be competitive with their own.

The situation now is much better than in the early years of the App Store, when in the absence of an official review guidelines document, developers relied on sparse and often contradictory pieces of advice found on quasi-professional websites. Although information can be found much more easily these days, we are still seeing a decent number of rejected applications, often because of trivial reasons that could have easily been identified in advance.

Given the hundreds of published applications, there’s probably no team with more experience in the App Store approval process than we are at ShoutEm. We’ve seen everything: The Good, the Bad and the Ugly. It encouraged us to write this blog series about rarely mentioned, but no less important reasons why apps may be rejected and how you can make your apps successful.

The Obvious

Applications must not have bugs (at least the prominent ones), must not crash, or leak memory. The user interface should be developed according to Apple’s Human Interface Guidelines (HIG) and network unavailability should be detected and appropriately displayed to the user. Using an undocumented API method is strictly prohibited.

The Less Obvious

1. Application name

  • The name of the application must not be identical or similar to the name of another application that is already in the Store. Also, use of the word “trial” or “beta” in the title is not allowed.
  • The name of an iPad app must not be the format “iPad [app name]” or “[app name] iPad”. You are allowed to name the application “[app name] for iPad” (note the “for”), or “[app name] HD” or “[app name] XL”. This implies that “[app name]” is also yours, otherwise your submission will be rejected for violating the first rule above.
  • Contrary to popular belief, if you ever decide to change your mind about your app name, you will be able to change it later, even if the application is already in the Store.

2. Application Icon

  • If you create an application icon that is too different from its iTunes artwork, Apple will reject it. Of course, no one expects that your icon and artwork must be identical, but they must be similar to one another, use the same branding and a similar color scheme.
  • Just note that if you plan to offer a free and paid version of the application (e.g. “lite” and “pro”), icons for these two apps must not be same.

3. Application Description

  • The description must report the app’s purpose, as well as its functionality, from the perspective of your customer. Make sure that the description is accurate because the reviewers will check that it really relates to your app’s features!
  • Example: if you write that your application contains a video review of the latest action movie, and a reviewer finds an empty list of videos (because you didn’t have time upload one yet) the application will certainly be rejected.
  • Description of features or bug fixes for future versions of the app will also be reviewed. In order to reduce the risk of rejection on new app versions, some developers utilize minimal descriptions such as “Minor bug fixes.” Although this description is perfectly legal as far as Apple is concerned, it won’t provide sufficient incentive for many customers to download the new version. It is always better to make your descriptions more attractive and comprehensive.

4. App functionality

Apple doesn’t have anything against non-native applications, i.e. apps that have some or even all of their functionality implemented through a web browser using HTML/JavaScript technology. Gmail is one example of such an app, as is LinkedIn for iPad. However, it often happens that people, who desperately want their own application in the App Store, go with the path of least resistance and submit an app that doesn’t provide any real functionality other than displaying their website. Such applications will certainly be rejected, and the content is probably a better candidate for a mobile-friendly web site than for downloading.

5. In-App Purchases

  • Apple takes a 30% cut of any content, functionality, or service sold through your application and does not allow the sale of books, music, articles, additional game levels, or other virtual goods by any other method except the iTunes Store. An application with links such as a “buy” button that leads to a website selling a digital book will be rejected for sure, so it’s best to stay clear of such experiments.
  • Understandably, giving away 30% of your earnings may be unacceptable in many business situations. If you don’t want to use in-app purchase for your business, you’re not alone. If you decide not to use iTunes to sell your stuff, the best thing you can do, and still stay within the limits acceptable for Apple, is to set up a message in the application similar to this one: “If you want to buy a subscription, go to our web site.” (Without the link to the site, and without mentioning the web address!)

Like we said at the beginning, there are many different parts to think about, both big and small. And taking care of these sticky points before submission is only half the battle. In Part 2 of our series next week, we’ll fill you in on all the things that can happen after you submit your app for review.

Want to know more about the appeal process or expedite review? Read on in Part 2 of this series.

linkedin Acing the App Store Approval, Part 1: Understanding the Nitty Gritty