iphone Programming : Distributing Your Application - Submitting to the App Store, Reasons for Rejection

1. Submitting to the App Store

If this is the first time you’ve submitted an application to iTunes Connect, you’ll be asked what primary language you will be using to enter your applications to the store. You’ll then be asked what company or developer name you want displayed on the App Store for all your applications. Both your primary language and your company name cannot be changed, so choose carefully. You won’t be asked these questions again the next time you submit an application to the store.

You’ll then be asked whether your application uses encryption. If your application includes any encryption code, you may have to fill out some forms to comply with U.S. commercial encryption export controls.

Next, you’ll be asked to provide information about your application:

Application name and application description

The application display name and description will appear as is on the iTunes App Store. You do not have to use the same name for the application as you used for your project binary or bundle display name. However, it should be related to the display name, or this might form grounds for rejection by the review team. You should try to keep your description fairly short so that your application screenshots will be “above the fold” (the part of the description the user will see without having to scroll) if the user is browsing the store from her iPhone or iPod touch.

Device requirements

At the time of this writing, the choices were iPhone only, iPhone & iPod touch (2nd Generation), and iPhone and iPod touch. It’s best to select the least restrictive requirements you can to increase the number of possible users of your application.

Primary and secondary category

These are the App Store categories that best describe your application. You need only select the primary category.

Copyright, version, and SKU number

The copyright and version number entries are fairly self-explanatory. For copyright, you should list the copyright year and copyright holder’s name. For the version, provide the version number of the app (1.0 is a good place to start). The SKU (or stock-keeping unit) number must be a unique alphanumeric identifier that you choose for this product. Bear in mind that this SKU cannot be changed at any point, even with the upload of a new binary (and version) of the application, so while you can choose just about anything, it should be fairly descriptive but not version-specific.

Keywords

Application keywords are associated with the application binary and can be edited only when uploading a new binary, so think carefully about your choice of keywords for your application. Separate multiple keywords with commas, not spaces.

Application and support URLs

Again, this is fairly self-explanatory. These are two URLs which can be identical; they point to support information about your application. Applications without associated URLs, or with URLs pointing to blank pages, will not be approved. Your support information should be in place before you upload your binary to iTunes Connect for review.

Support email address

This is the email address that will be published to iTunes as the support address when your application is approved. It would be a sensible move to create a separate email address for each of your applications, rather than use a personal address. If your application becomes popular, you will receive a lot of email.

Demo account

If your application needs an account on an online service to be fully operative, supply an account name and password here. If you don’t, the review team will summarily reject your application.

After entering this metadata, you’ll be asked to rate your application under certain categories: Cartoon or Fantasy Violence; Realistic Violence; Sexual Content or Nudity; Profanity or Crude Humor; Alcohol, Tobacco or Drug User or References; Mature/Suggestive Themes; Simulated Gambling; Horror/Fear Themes; Prolonged Graphic or Sadistic Realistic Violence; and Graphic Sexual Content and Nudity. This will generate your App Rating (4+, 9+, 12+, or 17+) that will allow users to filter your application using the parental controls inside iTunes. If you don’t rate your application realistically, the review team may reject it during the review process.

You’ll then be asked to upload your application binary (which you must first compress into a ZIP file by right-clicking on your application bundle file and selecting Compress), your large 512×512-pixel icon image, and a number of screenshots. Your screenshots will be displayed on the App Store with your application, and each must be a JPEG or TIFF file that is 320×480, 480×320, 320×460, or 480×300 pixels in size.

Once you have uploaded all the requested files, you will be asked to set the price tier for your application, and the availability date. Your application will be made available on the store on this date, or whenever it leaves the review process and is approved by the App Store review team, whichever is later.

Warning:

The availability date, like all application metadata, applies to all versions of your application. If you later upload an update for your application and change the availability date to a date in the future, your current version will be removed from the App Store until that date arrives.

After setting the price, you will be offered the opportunity to localize all of the metadata you entered into several different languages, including Dutch, German, Italian, Japanese, Chinese, and several different dialects of English and French. You are not required to enter any localization for your application metadata, but if you are selling worldwide you may have better sales if both your application and its store entry are localized.

Finally, before posting your application for review by the App Store review team, you will be given the opportunity to review all of the information you have entered. If you find any mistakes, you can click on the tabs across the top to return to that stage of the process.

1.1. The App Store Resource Center

2. Reasons for Rejection

The App Store review process is somewhat opaque, but generally, if your application is rejected, the review team will cite the specific section of the iPhone Developer Program License Agreement that it violates in the rejection email. If you’re careful, you can avoid most of the common pitfalls and save yourself, and the review team, a lot of time.

Note:

Copies of the iPhone Developer Program License Agreement, the agreement you signed with Apple to become an iPhone developer, and the iPhone Human Interface Guidelines are available for download from the App Store Resource Center in the App Store Approval Process section at http://developer.apple.com/iphone/appstore.

Some of the more common reasons for rejection concern the following:

Version number

Applications submitted with version numbers less than 1.0, or applications tagged as “beta” or “alpha,” will be summarily rejected by the review team. Additionally, if there is any inconsistency in versioning—for instance, the version number in your application’s About dialog does not match the version number in your Info.plist file (and the number you provided to iTunes Connect)—your application may be rejected.

Icons

The artwork for your 57×57-pixel icon must be identical to your 512×512 icon. Additionally, if you are uploading a free “lite” version of your application as well as a premium “pro” version, the application icons cannot be identical between the two versions.

Artwork

Using Apple’s own graphics inside your application—for instance, logos or an image of an iPhone or iPod touch—is usually grounds for rejection.

Copyright material

Apple is extremely wary of allowing applications to make use of material (e.g., images, audio, and other media) that you do not have permission to use. Using material that might violate a trademark is similarly suspect.

Human Interface Guidelines

Violating the Human Interface Guidelines—for instance, using standard button icons for a nonstandard purpose, such as the Refresh, Organize, Trash, Reply, and Compose buttons—could be grounds for rejection.

Private frameworks

Applications published to the App Store are not allowed to link to private or third-party frameworks. Submitting applications for review that do link to such frameworks is an easy way to get your application rejected. Linking to third-party static libraries is a gray area, but is usually acceptable.

Existing functionality

A large number of applications have been rejected for duplicating existing functionality of a built-in app; applications that make extensive use of web browsers are particularly vulnerable to this accusation. Other obvious candidates are email clients and music player applications.

Table views

Improper handling of table view cells when the application has a table view in edit mode can be grounds for rejection, as can not deselecting table view cells appropriately after selecting them to perform some action.

Network reachability

Not testing for the presence of a network connection or not handling the loss of network connectivity correctly (and informing the user) is a common cause for rejection.

Bandwidth limitations

If your application makes use of large amounts of bandwidth, you need to make sure your current network connection is over the cellular network. Transferring large amounts of data over the cellular network can (sometimes) be grounds for rejection. So, if your application does that, you should disable, or throttle, data transfer when the device is on the cellular network.

Keyboard type

You should ensure that you are using the correct keyboard type when prompting for user input; using an inappropriate keyboard is usually grounds for rejection (e.g., using the keyboard designed to enter phone numbers for other purposes).

OS compatibility

If you claim that your application will run on OS 3.0 and later, you must ensure that it really does so. Apple will test your application with all of the versions of the OS between your minimum specified version and the current release. If the review team discovers that your application does not function correctly with a specific version of the OS, they will normally reject it. Unfortunately, it’s fairly rare for them to tell you in which version of the OS the bug manifested. This can lead to the unfortunate situation where you cannot duplicate the bug since you and the reviewer are testing the application under different OS revisions.

Description

Do not include the price in your application description, as part of your icon, or anywhere in the UI. According to Apple, this may “potentially confuse users” as the text cannot be localized to all markets.

Crippled functionality

If you provide a free “lite” version of your application, it cannot have crippled functionality (e.g., obviously disabled buttons or menu items). It also cannot directly refer to the paid “pro” version of the application. Free or “lite” versions of an application are acceptable, but the application must be a fully functional application in itself and cannot reference features that are not implemented.

Minimal user functionality

If your application doesn’t actually do very much, it might get rejected. However, there are numerous cases where applications that don’t do very much have been accepted (e.g., flashlight applications).

Does not work as advertised

Applications that do not work as described in their application descriptions will be summarily rejected. You should therefore be careful when writing your application description when submitting your application to iTunes Connect.