How to avoid App Rejection From Apple (iPhone /iPad)

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 experiences, here’s 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 512×512 iTunes Store icon match the 57×57 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, UILabel 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.

Private API:s

Calling private API:s has always been verboten. Some developer have tried to argue that some API components are “more private” than others. For example it seems less nefarious to pass in an undocumented parameter value to a public API than linking to a private framework. In the long run I think such distinctions are futile. If your business depends on your app being approved, then stay clear of anything that is not documented as official by Apple.

In the beginning a lot of apps got away with breaking this rule. Now Apple has more sophisticated scripts that scan your code looking for violations.

One particular API has been the source of some amusement: the private Coverflow API. Several developers, myself included, have had apps rejected for using this API when we in reality had spent a lot of time and effort in building a reasonable implementation of Apple’s coverflow user experience. I guess we should be flattered that Apple mistook our implementation for their own.

No Interpreted Code

You cannot create an app that downloads and executes code that was not present in the app bundle submitted to Apple. This rule puts the kibosh on emulators (NES, C64, etc) and effectively kills alternative web browsers (you would want to run JavaScript in the browser) as well as Flash.

Limited Functionality

This was a common rejection before the “fart category” was approved. In the beginning of the App Store it was not uncommon to see apps that simply opened a web view to a company’s web site. The goal was to get traffic to the web site, with the idea that competing with a few hundred apps was much easier than competing with millions of other web sites. With 140k apps, being noticed in the App Store is probably as difficult as on the web. In any case, Apple will reject simple UIWebView apps without any additional functionality.

Duplicates Functionality

This is a tricky one. There have been several high-profile cases where an app has been rejected for duplicating functionality of a built-in app. But having built a web browser app with parental controls that was approved without any major delay, I don’t know where the line goes.

Contests and Sweepstakes

Apple now allows both contests and sweepstakes within applications. The new rule, found in section 3.3.17, states, “Your Application may include promotional sweepstake or contest functionality provided that You are the sole sponsor of the promotion and that You and Your Application comply with any applicable laws,” adding that developers must “clearly state in binding official rules for each promotion that Apple is not a sponsor of, or responsible for conducting, the promotion.”

Handling of User Data

If you collect any user information and that data is sent to a server then you need to explain to the user what is about to happen and give an option to opt out. This applies, for example, to highscore and leaderboard liets. And even if the information submitted is just a bogus name that the user enters specifically for this purpose.

If your app uses Core Location for the sole purpose of serving ads or user tracking, then your app will be rejected. The use of Core Location needs to provide some benefit to the user. See Apple’s announcement.

Copyrighted Content

It goes without saying that you must have the rights to the content that you include in your apps. Recently Apple has begun checking and enforcing this more seriously. You need to know your copyright and trademark law to stay clear of violations. For example there have been several cases where developers have replicated old console games on the iPhone and the original owners of the game have complained to Apple resulting in the removal of the app from the App Store.

Use of Trademarked Images

If you display an image of an iPhone, or any other Apple product, inside your app it will be rejected unless you have received written approval from Apple to use that image. What exactly constitutes iPhone likeness? Some developers have reported that removing the home button circle is enough.

Objectionable Content

This is another big and sticky one without any clear guidelines from Apple. Here’s my experience:

  • Nudity is off limits, even with a 17+ rating.
  • For women in bikinis, images are rejected seemingly at random. One reviewer will object to a particular image and pass others, the next reviewer will find an objectionable image in the batch that the first reviewer passed. And on it goes.
  • Anything related to politicians will most likely be rejected.

The app reviewers seem to go to great lengths to find objectionable content by explicitly searching for swear words, or seeking out specific ebooks to download which may contain anything objectionable.

Another source of hilarity is content that actually doesn’t exist in the app. Remember the Twitter client that was rejected for displaying a trending hashtag that contained a bad word? To the app reviewers defense I must say that it can often be very difficult to know what content comes from the app itself and what is coming from a different source. The result seems to be that the source doesn’t matter. If it’s displayed within your app, you’re responsible for it. See also the next section about web views.

UIWebViews

If your application has a web view that allows unrestricted access to the Internet where scary things lurk, then you are automatically slapped with a 17+ rating. Why the built-in Safari app is not consequently shielded from minors is a mystery. But those are apparently the rules.

Now unless you are building a web browser, it seems unnecessary for you to allow full and unrestricted access to the Internet from within your app.

Transactions Outside The App Store

Apple doesn’t want you to conduct any commerce outside the App Store. Before In-App Purchasing was available we developed an app that allowed the user to purchase additional credits using a third party payment service. That feature had to be removed. Another of our clients has a calling card type app. If you have a calling card you typically have an account that you may want to check the balance of, and you may want to add more money to it using your credit card. It took several submissions to get the wording surrounding these features to Apple’s liking. In the end all references to an account were removed and all links to the vendor’s web site opened Safari instead of an internal web view.

Price Information

Do not display the price of an application inside your app or in your application description. The very reasonable explanation for this is that App Store prices/currencies vary from country to country.

iPad Specific Rejections

Support all four orientations

The iPad Human Interface Guidelines state that an iPad application should be able to run in all orientations. There are certain applications that need to run in the portrait orientation, it would be appropriate to support at least both variants of this orientation in your application. Supporting all four orientations, each with unique launch images, provides the best user experience and is recommended.

Popovers

Do not launch one popover from within another popover. The iPad Human Interface Guidelines state that only one popover element should be visible onscreen at a time.

More Advice

Unfortunately this list is not complete, as only Apple knows the extent of the hidden rules. Also, with a few exceptions that are anecdotal or widely known, the items on this list are rejections that I and my colleagues have personally experienced.

Here is a list of tips from Apple: App Store Submission Tips. It only contains a handful of items at the moment, but it’s a good sign from Apple. Since this should count as the official word from Apple, I sincerely hope that this list will grow to encompass all the “hidden” rules that have been painstakingly discovered by developers over time.

Here are a couple of good resources with app rejection advice from other developers:

And some good humor:

                    

Both comments and pings are currently closed.

Comments are closed.

Powered by WordPress | Designed by: video games | Thanks to game news, Psychotherapie in Berlin and Webdesign Berlin