Friday, November 26, 2010

App Store Rejection Reasons



Your Ad Here

Bugs
One of the larger categories of App Store rejections is probably plain bugs. If the app crashes during the review testing it will be rejected. Test your app thoroughly before you submit it. Make sure you test it on multiple devices, different OS versions and specifically under varying network conditions. Since all developers hate testing their own code, write unit test code for your regression testing.

HIG

Discoverability is a problem with touch interfaces. (Hover with your finger above a button and see if you get any hints as to what the button does…) Users know how UI:s work by convention and they have been trained by Apple’s built-in apps. If you use a button image or a UI metaphor in an unconventional way, you will confuse users. This is why adherence to the HIG is so important, and why Apple is so nitpicky in enforcing it.

Here are some concrete examples of HIG violations:
  • Tapping an action button (a rectangle with an arrow coming out of it) must result in an action sheet where the user can select an action or cancel.
  • The same holds true for all built-in icons. Make sure that your app behaves exactly as Apple’s apps to when you tap one of these icons.
  • Don’t leave activity indicators spinning forever. This can easily happen if you don’t trap errors properly.
  • TableViewCells must not have state, i.e. make sure that the highlight is removed when the selection action is done. If you use a UITableViewController rows are automagically cleared for you when the screen is shown. If you’re rolling your own, add this to your code:
- (void)viewWillAppear:(BOOL)animated
{
 NSIndexPath *tableSelection = [self.tableView indexPathForSelectedRow];
 [self.tableView deselectRowAtIndexPath:tableSelection animated:NO];
}

Lite Versions

The rules surrounding Lite versions of apps are murky at best. I have not had any issues with this, but here are some items I’ve heard from other developers:
  • A Lite app cannot appear to be crippled. For example visually disabled buttons or sections of the app are not allowed.
  • You cannot prompt the user to upgrade to the full version.
  • You cannot display the price of the full version inside the Lite app.

Internet Connectivity

If your application depends on Internet connectivity and it’s not available, then you must display a message to the user. This is actually trickier than it sounds to implement in your code. Most people base their connectivity checks on Apple’s Reachability code, which is using that sample code for the wrong purpose. If you need to get data from a specific server, then try to download some data from that domain. If that’s successful then you have the necessary connectivity. A special case to test for is WiFi hotspots that require a login to get online. Go to your nearest Starbucks and test your app. The Starbucks WiFi hotspots also have the additional quirk of allowing access to the apple.com domain, which may be what your connectivity test uses if you just copied Apple’s sample code.
It is my experience that Apple always tests applications under no connectivity conditions. Save yourself some approval time and test this yourself first.

Excessive Bandwidth Usage Over Cellular Networks

“Bandwidth hogs” was on Apple’s original list of forbidden fruit when the SDK was introduced. Unfortunately they have never defined exactly what the limits are. If you streaming or downloading a lot of data, make sure your application knows what type of network is in use and it has the ability to throttle or switch to a stream with a lower bit rate if necessary.

Device Capabilities

There are a few differences between the various iPhone and iPod Touch generations. Don’t assume that the device running your app has a particular capability. In one app I had a settings screen where the user could turn off vibrations. That setting obviously has no effect on an iPod Touch, and the app was thus swiftly rejected.

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 appwith 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.

App Icon and App Store Image

The 57×57 application icon and the 512×512 App Store Image must depict the same thing.

Application Description

This doesn’t have to do with development per se. But when write the App Store description make sure that you are describing the application correctly. If you describe a feature that is not there, then you will be rejected.
The same is true for the update notes. If your app update doesn’t exactly address the things you list in the “what’s new in this version” notes, you will be rejected.

App Store Keywords

The keywords you enter for your application have to be relevant, as Apple sees it. If your app is about football, don’t use a basketball keyword just because you think there’s an overlap in the demographics. And don’t use trademarked words, e.g. ESPN, or names of other App Store apps.
The punishment is that you’re app will be rejected, not just the description. You have to resubmit the binary and go to the end of the line.

Updates Are Reviewed As New Apps

Just because your app was approved once doesn’t mean that the original features are “safe” when you submit an update. It appears that all updates are reviewed as if they were brand new apps. A HIG violation that has been approved 5 times may be caught and rejected on your 6th app update.

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.
Until that happens, here are a couple of good resources with app rejection advice from other developers:
And some good humor:
UPDATE: Apple has finally published the App Store Review Guidelines. I will keep this page live for historic reasons, but hopefully it will not need to be updated any more since Apple describes their guidelines as a living document that will be amended over time as they craft new rules.

Posted by at

1 comment:

Subscribe to: Post Comments (Atom)
 
Submit Express Inc.Search Engine Optimization Services