Distributing Your Application - Learning iPhone Programming (2010)

Learning iPhone Programming (2010)

Chapter 9. Distributing Your Application

At this point, you have several applications that are almost ready to distribute, and perhaps you have ideas for your own applications and you want to start writing your first application and publish it to the App Store. However, before you can do that, you have to do some more housekeeping.

Adding Missing Features

Two things have been missing from your iPhone applications, the first being the lack of a custom icon. This is crucial for the marketing of your application; you need to bring your application design together to present it to users. When a user scrolls through a long list of possible applications on the App Store, applications with strong icon design stand out. But remember that the user has to look at your application’s icon every time he looks at the iPhone’s home screen. The icon has to be distinctive to stand out, but it also has to be attractive so that the user is willing to keep your application around. I’ve uninstalled otherwise good applications because I couldn’t put up with their icons, and I’m not alone.

Adding an Icon

The standard iPhone home screen icon used for your application is 57×57 pixels square in PNG format with no transparency or layers (Icon.png). You also must provide Apple with a 512×512-pixel version of your application icon for display on the App Store (iTunesArtwork with no extension; you will need to provide this when you upload your app). This larger image must be in TIFF or JPEG format, and again have no transparency or layers.

It’s sensible to design your icon as 512×512 pixels and scale it down to the 57×57-pixel version supplied inside your application’s bundle. Doing things the other way around usually means that an unattractive and often pixelated icon is shown on the App Store.

Note

You can also provide a small icon, as a 29×29-pixel PNG file, in your application bundle called Icon-Small.png. Spotlight will use this icon on the device when the application name matches a term in the search query. Additionally, if your application includes a Settings Bundle (see Chapter 12 for more on Settings Bundles), this icon is displayed next to your application’s name in the Settings application. If you do not provide this icon, your 57×57-pixel image is automatically scaled and used instead.

Both the iPhone and the iTunes store will, by default, apply some visual effects to the icon you provide. They will round the corners, and add both drop shadows and reflected shine.

You can prevent iTunes from adding visual effects by setting the UIPrerenderedIcon flag inside the application’s Info.plist file. To do so, open the <ApplicationName>-Info.plist file for your project in the Xcode editor (it’s in the Resources folder under Groups & Files) and click on the bottom entry, where a button with a plus sign on it will appear to the righthand side of the key-value pair table. Click on this button to add a new row to the table, and scroll down the list of possible options and select “Icon already includes gloss and bevel effects,” as shown inFigure 9-1. When you’ve done so, check the box in the Value column to turn off the default visual effects added by both iTunes and the iPhone.

Adding the UIPrerenderedIcon flag to our application’s Info.plist

Figure 9-1. Adding the UIPrerenderedIcon flag to our application’s Info.plist

Let’s generate an icon for the City Guide application we built in Chapter 5. Figure 9-2 shows a sample image from the Tango Desktop Project, which was released into the public domain and is available from Wikimedia Commons. You can find many public domain images at Wikimedia Commons. It’s advisable for you to make modifications to the images you find there to avoid possible confusion—because the images are public domain, other people may use them in their own applications.

A simple icon for our City Guide application

Figure 9-2. A simple icon for our City Guide application

You can download the icon shown in Figure 9-2 from http://commons.wikimedia.org/wiki/File:Applications-internet.svg (right-click or Ctrl-click the link labeled Applications-internet.svg and choose Save Linked File). Open it in an image editor such as Adobe Illustrator or the free and open source Inkscape.

Resize the file to 57×57 pixels and save it as a PNG file named Icon.png. (If you are using Inkscape, you will need to use File→Export Bitmap, choose the Page option, and set the width and height to 57 before you click Export.)

Next, open the City Guide application in Xcode. Drag and drop the Icon.png file into the Resources group in the Groups & Files pane, making sure to tick the box to indicate that Xcode should “Copy items into destination’s group.” Now double-click on the CityGuide-Info.plist file to open it in the Xcode editor, and set the Icon file to Icon.png, as shown in Figure 9-3.

If you build and deploy the application by clicking the Build and Run button in the Xcode toolbar, the application will start inside iPhone Simulator. If you quit the application by clicking the Home button, you will see that it now has a shiny new icon, as shown in Figure 9-4.

Adding a Launch Image

One of the ways in which the iPhone and the iPod touch cheat is by providing launch images. A launch image is immediately displayed on the screen when the application is started before the UI is displayed. Your application displays the launch image file while loading, which means there are no more blank screens while the application loads.

Adding the icon to the Info.plist file

Figure 9-3. Adding the icon to the Info.plist file

The City Guide application with its new icon

Figure 9-4. The City Guide application with its new icon

Let’s add one of these to the City Guide application. Build and deploy the City Guide application onto your iPhone or iPod touch. While your device is still connected and your application is still running, open the Organizer window by going to Window→Organizer in the Xcode menu bar. You will see a glowing green dot next to your device. Select your device, and in the Screenshots tab click the Capture button. Xcode will take a screen capture from your application, as shown in Figure 9-5.

The Xcode Organizer window with a screen capture of the City Guide application’s UI

Figure 9-5. The Xcode Organizer window with a screen capture of the City Guide application’s UI

Click the Save As Default Image button and select your project from the menu. When you return to the project in Xcode, you’ll notice a Default.png image file appear in the Resources group in your project. If you rebuild the City Guide application at this point and redeploy it, the application will apparently now load instantly.

Although many developers have chosen to use the launch image as a splash screen, that’s not how Apple intended this image to be used. Instead, it is intended to improve the user experience. Its presence adds to the user’s perception that your application is quick to load and immediately ready for use when it does load.

Because this is a mobile platform, users will switch between applications frequently. Even more than on the Web, where users’ attention spans are notoriously short, on the iPhone and iPod touch, users will become frustrated with applications that take a long time to launch (or shut down). You need to work to keep the launch time of your application to a minimum, and use the launch image to make a subtle transition into your application.

The launch image measures 320×480 pixels, and generally should be identical to the first screen of your application. However, since this is an image, the content is static, so you should not include any interface elements that may change from launch to launch. Therefore, avoid displaying elements that might look different between the launch image and your first screen. For instance, the Default.png image file we generated for our City Guide application includes a list of cities, but what happens if the user adds more cities? The list will change. We can’t update the list of cities in the launch image, so it’s probably best to remove them, leaving only the table view as shown in Figure 9-6. (This also has the benefit of hinting to the user that she can’t interact with the app just yet.)

To do this, right-click on the Default.png image file in Xcode and select Reveal in Finder. This will open the Finder and highlight the image in your project folder. You can now open this image in your preferred image editor and make any changes you want. Remember, you need to save it back as a single-layer PNG file without transparency; otherwise, your application will have problems loading the file at launch.

A screen capture of the opening screen of the City Guide application (left), and the modified version (right) without the city entries

Figure 9-6. A screen capture of the opening screen of the City Guide application (left), and the modified version (right) without the city entries

Most applications’ launch images will be very plain; this is not a problem, as they are there solely to convince your users that your application is quick to load. If you interrupt the user experience with a splash screen, your users might ask themselves why you’re wasting their time displaying such a screen, and why you don’t just get on with it and load the application. If you make use of the launch image correctly, they’ll know that you’re doing your best to give them a seamless experience.

Changing the Display Name

The name displayed beneath your application icon on the iPhone home screen is, by default, the name of your Xcode project. However, only a limited number of characters are displayed before an ellipsis is inserted and your application name is truncated. This is fairly messy, and generally users don’t like it. Fortunately, you can change your application’s display name by editing the “Bundle display name” field in the application’s Info.plist file.

If you look at our City Guide application, you’ll notice that the display name is the same as our project name: “CityGuide”. While the name is not long enough to be truncated when displayed on the iPhone’s home screen, we might want it to be displayed as “City Guide” instead. Let’s make that change now.

Open the CityGuide project in Xcode and click on the CityGuide-Info.plist file to open it in the Xcode editor. Double-click on the Value field in the “Bundle display name” field and change the ${PRODUCT_NAME} macro to City Guide, as shown in Figure 9-7.

If you rebuild the application and deploy it in iPhone Simulator, you’ll notice that the name displayed below the City Guide application icon has changed from “CityGuide” to “City Guide”.

Setting the “Bundle display name” in the City Guide application’s Info.plist file

Figure 9-7. Setting the “Bundle display name” in the City Guide application’s Info.plist file

Enabling Rotation

Until now, all of the applications we have built in the book have been in portrait mode and would not rotate into landscape mode, as many iPhone applications do when the user rotates the phone. Enabling this functionality is actually amazingly easy. In your view controller class, add the following method:

- (BOOL)shouldAutorotateToInterfaceOrientation:

(UIInterfaceOrientation)interfaceOrientation {

// Return YES for all supported orientations

return YES;

}

If you rebuild your application and rotate your device, or if you select Hardware→Rotate Left or Hardware→Rotate Right in the simulator, your UI will rotate into landscape mode. If you have multiple view controllers (such as RootController.m, CityController.m, andAddCityController.m), you need to add this method to each of them.

Note

Although the shouldAutorotateToInterfaceOrientation: method was called in a timely fashion under the 2.0 SDK, this is not always the case under the 3.0 SDK. To ensure that you are (reliably) notified of changes in the device orientation, you should register for notification of orientation change messages.

However, the UI elements will also squash and stretch into the new orientation. You need to make sure that the individual UI elements can cope with their new sizes elegantly. You can do that in one of two ways:

§ Be careful when using the Size tab in the Inspector window in Interface Builder to make sure they stretch in the correct fashion. The easiest way to do this is to make use of the Autosizing, Alignment, and Placement sections in the Size tab.

§ Register for orientation change notifications and dynamically adapt your UI based on those events. For example, the built-in Calculator application has a different UI in portrait and landscape modes.

You can start generating orientation change notifications by calling this method of the UIDevice class (in the viewDidLoad: method of your view controller class):

[[UIDevice currentDevice] beginGeneratingDeviceOrientationNotifications];

When you are no longer concerned about orientation changes, you stop such notifications by calling this method:

[[UIDevice currentDevice] endGeneratingDeviceOrientationNotifications];

After starting notifications, you must also register your class to receive such messages using the NSNotificationCenter class:

NSNotificationCenter *notificationCenter =

[NSNotificationCenter defaultCenter];

[notificationCenter addObserver:self

selector:@selector(handlerMethod:)

name:@"UIDeviceOrientationDidChangeNotification"

object:nil];

This would invoke the handlerMethod: selector (elsewhere in your view controller) in the current class when such a message was received:

-(void) handlerMethod:(NSNotification *)note {

/* Deal with rotation of your UI here */

}

Building and Signing

The certificates we generated in Chapter 2 were intended only for development. If you want to distribute your application to end users, you’ll need to return to the Developer Portal, generate a different set of profiles, and rebuild your application, signing it this time with your new distribution profile rather than the development profile you have used thus far.

Note

The different provisioning profiles are used for different purposes. The development profile you generated in Chapter 2 is intended for development and your own devices. The ad hoc distribution profile is intended for alpha and beta testing, while the App Store distribution profile is intended for distributing your final build to the iTunes App Store.

Ad Hoc Distribution

Ad hoc builds of your application are used to distribute your application outside your own development environment, and are intended to allow you to distribute your application to beta testers. In the same way you registered your iPhone or iPod touch for development, you must register all of the devices onto which you intend to distribute your application using an ad hoc build. You can register up to 100 devices per year in the iPhone Program Portal. This is a firm limit; deleting already registered devices will not allow you to add further devices.

Note

Normally when you distribute applications via the ad hoc method, no application artwork is displayed when the user looks at your application inside the iTunes interface. However, if you place a copy of the 512×512-pixel PNG of your icon in your application bundle and name it iTunesArtwork without any file extension, this will be used by iTunes.

To deploy your application to your users via the ad hoc method, you need to create a distribution certificate, register any devices you plan to use, and create an ad hoc provisioning profile in the iPhone Developer Program Portal.

Obtaining a distribution certificate

Just as in Chapter 2 when we dealt with development, the first thing you need is a distribution certificate, and to obtain that you need to generate a certificate-signing request (CSR) using the Keychain Access application:

1. As you did for the CSR you generated for the development certificate (see Creating a Development Certificate in Chapter 2), launch the Keychain Access application.

2. Select Keychain Access→Preferences from the menu. Go to the Certificates preference pane to confirm that the Online Certificate Status Protocol (OCSP) and Certificate Revocation List (CRL) options are turned off.

3. Select Keychain Access→Certificate Assistant→Request a Certificate from a Certificate Authority from the Keychain Access menu, and enter the email address you selected as your Apple ID during the sign-up process and your name. Click the “Saved to disk” radio button, check the “Let me specify key pair information” checkbox, and click Continue. You’ll be prompted for a filename for your certificate request.

4. Accept the defaults (a key size of 2,048 bits using the RSA algorithm) and click Continue.

The application will proceed to generate a CSR file and save it to disk.

In the iPhone Developer Program Portal (sign in to http://developer.apple.com/iphone and look for the program portal link), click on the Certificates link and in the Distribution tab click Request Certificate (if you already have a certificate, this option will be unavailable as you need only one). Follow the instructions that appear, and upload your CSR to the portal when asked.

If you joined the development program as an individual, you need to approve the signing request (in the Distribution tab of the Certificates section of the portal) before proceeding to download the new certificate. If you are part of a team, the nominated development team administrator needs to do this. After the request is approved, you may need to click on the Distribution tab to refresh the page. When you see a Download button, click it to save the certificate to disk.

Once the certificate file has downloaded, double-click it to install it into your Mac OS X login keychain, as shown in Figure 9-8.

The Keychain Access application showing the newly installed distribution certificate needed by Xcode for ad hoc or App Store distribution

Figure 9-8. The Keychain Access application showing the newly installed distribution certificate needed by Xcode for ad hoc or App Store distribution

Registering devices

Before you create the provisioning profile, you’ll need to register the devices you want the profile to support. To do this you’ll need the unique device identifier (UDID) of all of these devices. Once you have the device identifiers, you need to add your users’ devices in the same way you added your own development device in Getting the UDID of Your Development Device in Chapter 2.

In the Program Portal, click Devices, select the Manage tab, and click Add Devices. Enter a device name in the appropriate box and the UDID in the box labeled Device ID, and click the Submit button. (You can click the + button to add more rows so that you can add several devices at once.) You have now registered the device; you need to do this for all of the devices to which you intend to distribute ad hoc builds.

Creating a provisioning profile

Now you’re ready to create a mobile provisioning profile. Go to the Provisioning section of the iPhone Developer Program Portal, select the Distribution tab, and click New Profile.

Enter a profile name; you may be creating a number of ad hoc profiles, so naming your first distribution profile “Ad-hoc Distribution Profile” probably isn’t a great idea. You may want to name it after the application you’re distributing, so perhaps “City Guide Beta Test Profile” would be a good choice for distributing a beta of the City Guide application to testers.

Next, select the App ID you used for the application you’re going to distribute, and then select all of the devices for which this profile will be valid, as shown in Figure 9-9.

Creating an ad hoc provisioning profile

Figure 9-9. Creating an ad hoc provisioning profile

Click Submit to generate the new mobile provisioning profile that you’ll use to distribute the application to your beta testers. The status will appear as pending; click the Distribution tab to reload it until it is no longer pending. When the profile is ready, click the Download button and download the provisioning profile to your Mac. Now drag the provisioning file onto the Xcode icon in the dock to make it available to the development environment.

Building your application for ad hoc distribution

Let’s make an ad hoc build of the City Guide application. Double-click the project icon at the top of the Group & Files pane and select the Configurations tab. Select the Release configuration in the main pane, and click the Duplicate button located at the bottom left of the configuration list. Name the duplicate configuration “Ad-hoc”, as shown in Figure 9-10.

Creating an ad hoc configuration in the Xcode Project Info window

Figure 9-10. Creating an ad hoc configuration in the Xcode Project Info window

Return to the main Xcode window and use the Overview drop down to set the active configuration to be the new ad hoc configuration, and the active SDK to be the iPhone device rather than iPhone Simulator.

Now, in the Groups & Files pane of the Xcode interface, right-click on the Resources group and select Add→New File. Choose Code Signing and select an Entitlement (see Figure 9-11). Click Next, and name the file “dist.plist” when prompted. Click Finish.

Adding the ad hoc distribution plist file to your project

Figure 9-11. Adding the ad hoc distribution plist file to your project

In the Groups & Files pane, click on the dist.plist file and (very important) uncheck the get-task-allow Boolean property in the editor window, as shown in Figure 9-12. This step is necessary to turn off the ability for other processes (such as the debugger) to attach to your application, as this is disallowed by distribution profiles.

Unchecking the get-task-allow flag in the dist.plist file

Figure 9-12. Unchecking the get-task-allow flag in the dist.plist file

Now, double-click on the project icon at the top of the Groups & Files pane to reopen the Project Info window. Click the Build tab and scroll down to the Code Signing section. Double-click on the Code Signing Entitlements value field, type dist.plist in the entitlements list, and click OK. Now click on the menu to the right of the Code Signing Identity→Any iPhone OS Device line and select the iPhone Distribution profile. Xcode should match this against the City Guide Beta Test profile we installed earlier, as shown in Figure 9-13.

Choosing the iPhone Distribution profile

Figure 9-13. Choosing the iPhone Distribution profile

Close the Project Info window. Before building your application, open the CityGuide-Info.plist file and make sure the Bundle Identifier in your Info.plist file matches the one used to create the ad hoc mobile provisioning profile. See Putting the Application on Your iPhone inChapter 3 if you’re unsure about this part. If you’ve been able to deploy your application onto your iPhone or iPod touch and you generated a wildcard app ID earlier, you shouldn’t have to change anything.

Now select Build→Build from the Xcode menu to build, but not to deploy, your application. You may be prompted to allow Xcode to access your private key by the Keychain application; you must permit the access to build the application.

Distributing an ad hoc build

Once you’ve made your build, go to the Products group in the Groups & Files pane in the Xcode interface and double-click to open the group if it is not already open. Inside you should find a single file called CityGuide.app. Right-click on this file and select Reveal in Finder to open a Finder window in the directory containing the application bundle.

Copy the application bundle file onto your desktop and create a ZIP file containing both it and the ad hoc mobile provisioning profile you created earlier. This ZIP file is your ad hoc build and can be distributed directly to your users.

Users receiving an ad hoc build should follow these steps:

1. Plug their iPhone or iPod touch into their Mac.

2. Ensure that iTunes is running and can see their device.

3. Unzip the distribution archive file.

4. Drag the provisioning profile onto the iTunes icon in the dock.

5. Drag the application bundle file onto the iTunes icon in the dock.

If the user checks the Applications section of his iTunes library, he should now be able to see the new ("Ad-hoc”) application, and he can install it onto his iPhone or iPod touch in the normal way by syncing his device with iTunes.

Developer-to-Developer Distribution

Apple intended ad hoc distribution to be a way for you to distribute your software to beta testers. However, developers have used it extensively for other purposes, including bypassing the App Store entirely and selling directly to the consumer (a somewhat torturous process).

If your intended end user is another developer, you can vastly simplify the ad hoc distribution process. Just create a normal development build, as though you were going to deploy the code to your own device, and send a copy of the binary to your colleague. He can then re-sign the binary with his own developer certificate using the Xcode command line codesign utility:

#! /bin/bash

export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform\

/Developer/usr/bin/codesign_allocate

codesign -f -s "iPhone Developer" $1.app

Once he has re-signed the binary, he can use the Xcode Organizer window to install it onto his device. In the Applications section of the Summary tab, he should click the + symbol and select the binary. Xcode will then install it onto his iPhone or iPod touch.

App Store Distribution

Making a build of your application to submit to the App Store is similar to making an ad hoc build, and you’ll use the same distribution certificate you created for the ad hoc build earlier in the chapter. However, you have to return to the iPhone Program Portal to generate a new distribution provisioning profile.

Open the iPhone Developer Program Portal in a browser (start at http://developer.apple.com/iphone/ and follow the links to the Program Portal), and in the Provisioning section, select the Distribution tab and click New Profile. Enter a profile name; you’ll need only one App Store profile, so unlike the ad hoc profile, a good choice might be “App Store Distribution Profile”.

Note

Most developers use one (wildcarded) App Store distribution profile for all of their applications (see Putting the Application on Your iPhone in Chapter 3). The only reason you would need to use a separate profile for your application is if it makes use of In-App Purchase or Push Notifications.

Finally, select the App ID you used for the application you’re going to distribute; since this is an App Store provisioning profile, there is no need to select devices this time around.

Click Submit to generate the new mobile provisioning profile. The status will appear as pending; click the Distribution tab to reload it until it is no longer pending. When the profile is ready, click the Download button and download the provisioning profile to your Mac. Drag the provisioning file onto the Xcode icon in the dock to make it available to the development environment.

Building your application for App Store distribution

Let’s make an App Store build of our City Guide application. Double-click on the project icon at the top of the Groups & Files pane and select the Configurations tab. Select the Release configuration in the main pane, and click the Duplicate button located at the bottom left of the configuration list, just as you did for the ad hoc build, but this time around name the duplicate configuration “Distribution”.

Return to the main Xcode window and use the Overview drop down to set the active configuration to be the new distribution configuration, and the active SDK to be the iPhone device rather than iPhone Simulator.

Now double-click on the project icon at the top of the Groups & Files pane to reopen the Project Info window. Open the Build tab and scroll down to the Code Signing section. Click on the menu to the right of the Code Signing Identity→Any iPhone OS Device line and select the App Store distribution profile. Xcode will not automatically match this profile by default as it did with your developer profile. You must make this selection manually, as shown in Figure 9-14.

Choosing the App Store distribution profile manually

Figure 9-14. Choosing the App Store distribution profile manually

Close the Project Info window. Before building your application, check the Info.plist file for your app (such as CityGuide-Info.plist) and make sure the Bundle Identifier matches the one used to create the App Store provisioning profile. Now select Build→Build from the Xcode menu to build, but not to deploy, your application. Unless you’ve already clicked Always Allow on a previous build, you’ll be prompted to grant access to your keychain. You must allow this access.

Once you’ve made your build, go to the Products group in the Groups & Files pane in the Xcode interface and double-click to open the group. Inside you should find a single file called CityGuide.app. Right-click on this file and select Reveal in Finder to open a Finder window in the directory containing the application bundle. Copy the application bundle file onto your desktop. It’s this file that you’d upload to the iTunes Connect site to release it onto the App Store.

Submitting to the App Store

Note

While I’ve walked you through building a version of the City Guide application that is ready to be submitted to the App Store, you should not actually go ahead and submit it. The App Store might start to look a bit odd if every reader of this book did that.

Log in to the iTunes Connect site, and click the Manage Your Applications button and then the Add New Application button.

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.

The App Store Resource Center

If you’re confused about any aspect of distribution, you should make your way to the App Store Resource Center. This site walks you through the process of preparing your application for submission, the App Store approval process itself, and how to manage your applications on the store once they’re live.

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.