I've been developing apps for the iPhone for over 6 months now. Over this time period, I've successfully submitted over 45 apps, the majority under my own company's iTunes account. Given the large number of app submissions, I've had my share of app rejections.
As has been mentioned many many times on the various developer forums, Apple's approval process can be very frustrating and inconsistent. However, if you are careful, you can greatly reduce your risk of getting an app rejected.
Based on my own experiences, here's my list of things to be careful about:
1. The dreaded HIG Violation of Apple's Human Interface Guidelines (HIG) is probably the most frequent cause for an app to be rejected. As an iPhone developer, you definitely need to read the HIG and follow the guidelines! Take every single item mentioned in the HIG seriously. Yes, many apps demonstrate gross violations of the HIG (after all, splash screens are a no-no according to the HIG), but you can never claim "App X does this and is already in the store" as an excuse when Apple rejects your app. Well, you can claim that, but Apple will not accept it as a valid justification.
There are certain items in the HIG to which Apple does seem to turn a blind eye (splash screens probably being the most obvious), but unless you like taking chances with your livelihood, avoid going against any of the HIG guidelines.
2. Matching icons Believe it or not, Apple is now requiring the 512x512 iTunes Store icon match the 57x57 icon displayed on the iPhone. As a reason for rejection, Apple will state having unmatching icons is in violation of the HIG. There's nothing in the HIG that states these two icons must match, but since it's Apple's store, you basically need to play by their arbitrary rules. So, unless you want unnecessary delays in your approval, make sure your icons match. The icons don't have to be identical, but there should be something shared between the two. Just having them both be pictures that are of a similar theme is not enough.
3. Simulating failures Apple doesn't like anything that pretends the iPhone or iPod Touch is failing. So, simulating a cracked screen is a good way to get your app rejected. Any other idea of faking a failure of the iPhone which you might think others would find amusing will probably also be a reason for rejection from Apple.
4. Button images must be consistent If you decide to use one of the existing images Apple provides for buttons, be careful you use it for an identical function. While the HIG states you can use a standard button in a non-standard way if your app is providing a "immersive environment", you are better off creating your own custom buttons to avoid the risk of rejection. If you use the "action button" image, make sure tapping on it brings up a menu with choices. If it doesn't, Apple may reject the app.
5. Bandwidth usage over cellular networks If your app downloads data over the cellular network, ensure you do not use too much bandwidth. How much is too much? Well, there isn't an exact number, but a tech support person from Apple advised me to not exceed 4.5 meg of data per 5 minutes of activity. You can test your app's usage by going into your iPhone settings, choosing the General->Usage menu and clearing the stats. Then run your app for 5 minutes, return to this screen and see what the stats say. Also, to get the most accurate numbers, you should turn off any other network activity on your phone while you run the test (such as Email or MobileMe updates).
6. Popup for network detection If your app requires the use of the Internet, you must detect when the network is unavailable and provide a pop-up message informing the user. Just having the spinning busy icon display and a message saying "trying to connect" is not sufficient. Apple will reject your app if you don't provide a message informing the user that they need a network connection.
7. False claims of a missing network On a related note, make sure you don't have any false positives in your network detection. There's a bug in the "reachability" functions provided by Apple. If you don't first try to perform a network connection but instead just do a reachability test, the code will always report the network is unavailable. Apple will reject your app if they discover you have this false positive case.
8. Political lampooning Don't make any jokes about political figures, past or present, in either your app or the description in iTunes. Apple will most-likely reject your app.
9. Ensure your app description is accurate Spend some time proof-reading your app description for iTunes. This description is the only information the reviewer is going to have about your app. Make sure there isn't anything ambiguous in the description. If there is room for misunderstanding a feature, you run the risk of the reviewer rejecting the app because they felt the app does not behave as described.
10. Keep your "what's new" descriptions brief Whenever you submit an update, Apple requires you to provide a description of what is new in the app. Related to the previous note above, try to be as clear and concise as possible. Don't go into too much detail describing what has changed, otherwise you introduce more opportunity for the reviewer to misunderstand what has changed. I've had an app rejected because the reviewer misunderstood what I said had changed in the app.
11. OS compatibility If you claim your app works with OS 2.0 and higher, you better make sure you test whether your app really does work on all the OS versions between 2.0 and the current one. The reviewer most-likely will! There are some anomalies in the behavior of certain functions across the different versions of the OS (for example, reachability code returns a slightly different set of flags under 2.0 vs. 2.2, UILabels don't respond to the Touch events under 2.1 and earlier, etc.). If the reviewer finds the app does not work properly with a certain version of the OS, the app will rightly be rejected. However, don't expect the reviewer to mention that they were testing using a different OS. That little detail is usually not mentioned in the rejection email, leading to the potential for lost time trying to find a bug while testing with a different OS than the reviewer. Again, test the app with every version you claim to support.
This is by no means an exhaustive list. It's just the things I've personally run into in my app submissions and is a laundry list of items I keep in the back of my mind whenever I'm developing a new app.
If you do find your app is rejected, the best advice I can give is try to remain calm. Remember there are thousands of other developers in your shoes. We feel your pain. It often feels unfair, and perhaps it is unfair at times. It can be a terribly frustrating experience, especially when you've done your best to follow every guideline Apple provides and you might be convinced Apple is wrong in their assessment of your app.
But, it's Apple's store. They can do whatever they want in the end and don't have to be fair. If you feel your app has been wrongfully rejected, the best you can do is be courteous and try to outline your position, quoting from whatever relevant Apple documentation applies. But, in the end, don't expect Apple to yield to your request, or in many cases, even acknowledge your request. Apple is generally very brief in their email responses and sometimes totally silent. The best bet for an approval is to implement a change based on Apple's reason for rejection and move on. Trying to win an argument because you feel you are right is not going to be productive.
And if you do get a rejection, add it to your list of things to avoid for the next app.
Posts
