Within the Xcode project editor, you will notice there are many configuration settings that are redundant between project-level and target-level settings. Here are a few pointers that will help you figure out which setting Xcode ultimately utilizes during the build process:

Figure 5-1. Using the Levels display to determine target settings

This section details how to properly set the “Bundle identifier” setting in your Xcode project with your App ID from the iOS Provisioning Portal. As discussed in previous chapters, before you distribute your build, it has to be signed by a Development or Distribution Certificate using a Provisioning Profile. As you know by now, Provisioning Profiles (Development or Distribution) are associated to a specific App ID at creation time. In order for your app to be signed, the Bundle ID portion of your App ID has to be correctly entered into the target settings of your app within Xcode. To summarize: you need to set up your Xcode project so that the Provisioning Profile on your computer is valid for the app you are building.

Take a moment to log in to the iOS Provisioning Portal and go to the Provisioning section. For the Development and Distribution Provisioning Profiles associated to the app you are building, make a note of the App ID these profiles are using. The App ID should be the same for both. From there, go to the App IDs section and make a note of the Bundle ID portion of the App ID. We are going to input that Bundle ID into Xcode. If your Bundle ID ends with a wildcard (*) character, you will have to replace the asterisk with a string of your choosing. Use Table 5-1 to help you determine the Bundle ID portion of your App ID. In a nutshell, everything to the right of, but not including, the decimal point after the “Bundle Seed ID” will be used to populate the Xcode “Bundle identifier” setting.

Setting the Bundle ID

Within Xcode, follow these steps to set the “Bundle identifier” for your app (see Figure 5-2):

1. Go to View → Navigators → Show Project Navigator.

2. Select the root project folder.

3. Within the project editor, select your target in the TARGETS section.

4. Select the Info tab.

5. By default, Xcode sets the Bundle identifier to something similar to com.appname.${PRODUCT_NAME:rfc1034identifier}. Change the “Bundle identifier” setting to match your Bundle ID. This setting is case-sensitive, and make sure there are no extra spaces after the Bundle identifier.

Figure 5-2. Setting the Bundle Identifier for your app

Verifying the Bundle ID

Follow these steps to verify that the Bundle identifier you have set for your app’s target is correctly associated to your Provisioning Profile(s) (see Figure 5-3):

1. Select your target, and go to the “Build Settings” tab.

2. Verify the view settings are set to All and Combined.

3. Within the Code Signing section, expand all settings for all build configurations by pressing the gray triangle to the left of “Code Signing Identity”. If the Bundle identifier matches the App ID associated to the Provisioning Profile, you will be able to set your “Any iOS SDK” to the respective Provisioning Profile. By default, Xcode sets the “Any iOS SDK” (for both default Debug and Release build configurations) to the Development Provisioning Profile.

   • For the Debug build configuration, the “Any iOS SDK” setting will be set to ‘iPhone Developer (currently matches “iPhone Developer: Development_Certificate_Name in Development_Provisioning_Profile_Name”),’ which indicates that the “Bundle identifier” you have specified for your app matches the installed Development Provisioning Profile.

   • For the Release build configuration, your Distribution Provisioning Profiles can be verified to work with your app’s Bundle identifier setting by successfully changing the Code Signing Identity → Release → Any iOS SDK setting to either your Ad Hoc or App Store Distribution Provisioning Profile. The setting will then be in the form of “iPhone Distribution: Distribution_Certificate_Name”. Choosing the “iPhone Distribution” profile within “Automatic Profile Selector” will also select a Distribution Provisioning Profile, and change the setting to ‘iPhone Distribution (currently matches “iPhone Distribution...”)'.

Note

If you install a Provisioning Profile while Xcode is open, you may be wondering why the Xcode project editor doesn’t “see” your new profile but Organizer does? Try toggling back and forth between your project and target to refresh the view, or restart Xcode.

Figure 5-3. The Bundle ID matches the Provisioning Profiles

Xcode allows you to set the version of the SDK it will use to compile your app. It is a best practice to use the Latest SDK setting to build your app for optimal performance, as the latest SDK version always has the most updated libraries, frameworks, integrated compilers, and so on. Unless you have a very specific reason not to use Latest SDK, verify this setting at both the project and target levels of your app.

To set the Base SDK at the project level (see Figure 5-4):

Figure 5-4. Setting the Base SDK for the project

For each target within your app, set the Base SDK (see Figure 5-5):

Figure 5-5. Setting the Base SDK for the target

At some point during the development cycle, you should determine the lowest version of iOS device software your app is going to run on. This decision could be driven by an API your app utilizes that isn’t available in earlier versions of iOS, or a hardware requirement that isn’t available on devices with older versions of iOS. The “Deployment Target” setting will be reflected as the minimum iOS software version required for your app to customers on the App Store. For example, if you designate a Deployment Target setting of 5.1, your app will be noted on the App Store as “Requires iOS 5.1 or later.” If a user attempts to install your app onto a device running an iOS version lower than 5.1, she will receive an “Application Not Compatible” error message. Keep in mind that the higher the iOS version your deployment target is set to, the fewer customers will be able to run your app; you will be excluding those customers from installing your app because they are running an older version of iOS on their device.

Follow these steps to set the iOS Deployment Target for your app’s target settings:

Figure 5-6. Setting the iOS Deployment Target for the target

Setting the Deployment Target iOS version for your app has a direct impact on the hardware architecture settings. As of Xcode 4.5, the default hardware architecture is set to ‘armv7 armv7s’. Older devices such as the iPhone3G and the 2nd generation iPod touch have the armv6 hardware architecture. If your app has an iOS Deployment Target of 4.2 or less, you’ll have to add the armv6 architecture to accommodate devices with the armv6 architecture. Pragmatically speaking, if your iOS Deployment Target is set to 4.0, but you have not added the armv6 architecture, you will not be able to install your app on an iPhone3G or a 2nd generation iPod touch, both of which may be running iOS 4.2.1. Inversely, you may have a project in which you no longer support an iOS version less than or equal to 4.3, so you may use this methodology to remove the armv6 hardware architecture setting.

To explain how to add an additional hardware architecture to your app’s target, we’ll walk through adding the armv6 hardware architecture to an Xcode 4.5 target. Additionally, you’ll need to add the armv6 hardware architecture to the target setting of each third-party library your app utilizes:

By default, all new Xcode projects are created with the Default and Release build configurations. You may encounter a scenario in which you wish to add another build configuration for your project. Example use cases for doing this may be: you wish to build your app with a different bundle id, you may want to use a different provisioning profile to access the keychain, etc.

Follow these steps to add an additional build configuration to your project:

Figure 5-9. Adding a new build configuration

Review the following list regarding app icons and launch images for an iPad-only app (see Table 5-2):

The following is a code snippet from a sample AppName-Info.plist file which shows how icons and a custom launch image base filename can be defined for an iPad-only app:

<key>CFBundleIcons</key>
<dict>
        <key>CFBundlePrimaryIcon</key>
        <dict>
                <key>CFBundleIconFiles</key>
                <array>
                        <string>[email protected]</string> 
                        <string>nextgreatapp-icon.png</string> 
                        <string>[email protected]</string> 
                        <string>nextgreatapp-icon-29.png</string> 
                        <string>[email protected]</string> 
                        <string>nextgreatapp-icon-50.png</string> 
                </array>
        </dict>
</dict>
<key>UILaunchImageFile</key> 
<key>CustomLaunchImage</key> 

Review the following list regarding app icons and launch images for an iPhone / iPod touch app. You’ll notice the list is a bit more complex than the list for an iPad-only app as an iPhone/iPod touch app can also run on the iPad, which results in providing additional icons (see Table 5-3):

The following is a code snippet from an AppName-Info.plist file which shows how icons and a custom launch image base filename can be defined for an iPhone / iPod touch app:

<key>CFBundleIcons</key>
<dict>
        <key>CFBundlePrimaryIcon</key>
        <dict>
                <key>CFBundleIconFiles</key>
                <array>
                        <string>[email protected]</string> 
                        <string>nextgreatapp-icon.png</string> 
                        <string>[email protected]</string> 
                        <string>nextgreatapp-icon-72.png</string> 
                        <string>[email protected]</string> 
                        <string>nextgreatapp-icon-29.png</string> 
                        <string>[email protected]</string> 
                        <string>nextgreatapp-icon-50.png</string> 
                </array>
        </dict>
</dict>
<key>UILaunchImageFile</key> 
<key>CustomLaunchImage</key> 

Review the following list for information on app icons and launch images for universal applications (see Table 5-4):

The following is a code snippet from an AppName-Info.plist file which shows how icons and a custom launch image base filename can be defined for a universal app:

<key>CFBundleIcons</key>
<dict>
        <key>CFBundlePrimaryIcon</key>
        <dict>
                <key>CFBundleIconFiles</key>
                <array>
                        <string>[email protected]</string> 
                        <string>nextgreatapp-icon-72.png</string> 
                        <string>[email protected]</string> 
                        <string>nextgreatapp-icon-57.png</string> 
                        <string>[email protected]</string> 
                        <string>nextgreatapp-icon-29.png</string> 
                        <string>[email protected]</string> 
                        <string>nextgreatapp-icon-50.png</string> 
                </array>
        </dict>
</dict> 
<key>UILaunchImageFile~ipad</key>  
<string>iPadImage</string> 
<key>UILaunchImageFile</key> 
<string>iPhoneImage</string> 

During the development phase of an iOS app, building and running your app on the iOS Simulator is the fastest way to verify that your app builds and loads without error. Here are few tips regarding the iOS Simulator:

iOS Simulator Build

In the upper-left corner of the workspace window, set the run destination to be your choice of Simulator device hardware and iOS version. Press the Run button to compile your app (see Figure 5-10). Upon successful build, the iOS Simulator opens and your app will be loaded into the interface.

Figure 5-10. Setting the Run Destination to the iOS Simulator and running the build

This section covers a typical “development” build scenario in which your app is compiled and deployed by Xcode to your iOS device, which is connected locally to your computer by the USB cable. Use the following bullet points as a pre-build checklist to verify your environment is set up properly.

Development Build

Follow these steps to build and deploy your app to a locally connected device:

1. Press the Scheme menu button in the upper left corner of the Xcode toolbar. Using the pop-up menu, choose “Edit Scheme” (see Figure 5-11).

   Figure 5-11. Using the Scheme Pop-up menu to modify a scheme

2. For the Debug task, verify the “Build Configuration” is set to Debug (see Figure 5-12). Press OK to close the scheme editor.

   Figure 5-12. For a Development build, set the Build Configuration to “Debug”

3. In the upper-left corner of the workspace window, set the run destination for the Scheme menu to your device, for example: iPhone. Press the Run button to initiate the build (see Figure 5-13).

4. Your app will install to your device and open.

Figure 5-13. Verify that the run destination is set to your device and run the build

Tip

The first time Xcode attempts to sign your app using your Development Certificate, you will be prompted by Xcode for permission to access to the keychain. Choose the Always Allow button (unless you wish to be prompted by Xcode to access the keychain every time you do a development build).

Warning

If your build fails with a CSSMERR_TP_NOT_TRUSTED error, you do not have an Apple WWDR certificate installed within the keychain your build process is using (see Adding the Apple WWDR Certificate).

This section covers how to build your app for Ad Hoc Distribution, which is the process of creating an application archive that can then be distributed to other users to install onto their (provisioned) devices for testing. This is the type of build you would do for users who will not be using Xcode to install your app onto their device(s). For Ad Hoc Distribution, you will build and package your app into an application archive (AppName.ipa file). Use the following bullet points as a pre-build checklist to verify your environment is set up properly.

Building for Ad Hoc Distribution

Follow these steps to build your app for Ad Hoc Distribution:

1. Press the Scheme menu button in the upper left corner of the Xcode toolbar, using the pop-up menu choose “Edit Scheme” (see Figure 5-11).

2. For the Archive task, set the “Build Configuration” to Release, and verify that “Reveal Archive in Organizer” is selected (see Figure 5-14). Press OK to close the scheme editor.

3. In the upper-left corner of the workspace window, set the run destination for the Scheme menu to “iOS Device” (see Figure 5-15). This may be a bit non-intuitive, as you should not have an iOS Device connected to your computer at this point. Hint: The Product → Archive menu option will be grayed-out if you have any of the Simulator choices set as the run destination target.

4. Select the Product menu → Archive to build your app. When the build is complete, Organizer will open and the application archive will be listed within in the Archives tab (see Figure 5-16).

Note

If you have a need to distribute a Development build (which includes debug symbols), set the Build Configuration for the Archive task to Debug.

Figure 5-14. For an Archive build, set the Build Configuration to “Release”

Figure 5-15. Verify the build destination and run the build

Figure 5-16. An archived Build within Organizer

Packaging for Ad Hoc Distribution

Follow these steps to package your app for Ad Hoc Distribution:

1. Within Organizer → Archives tab, highlight the application archive you wish to distribute, and press the “Distribute...” button (see Figure 5-17).

2. For the “Select the method of distribution:” dialog box, choose “Save for Enterprise or Ad-Hoc Deployment” (see Figure 5-18) and press Next.

3. For the “Choose an identity to sign with:” dialog box, select your Distribution signing certificate (see Figure 5-18) and press Next.

4. Save the archive file to your Desktop. You now have an application archive (AppName.ipa file) that can be distributed to users (see Ad Hoc Build Distribution).

Figure 5-17. Share your build archive for Ad Hoc Distribution

Figure 5-18. Ad Hoc Distribution packaging options

Figure 5-19. Ad Hoc Distribution signing options

Follow these steps to install an Ad Hoc application archive (.ipa) file onto a device using iTunes:

Figure 5-20. An Ad Hoc build loaded into iTunes

Figure 5-21. App settings for an iOS device

Follow these steps to install an Ad Hoc application archive (.ipa) file onto a device using iPhone Configuration Utility:

Figure 5-22. Installing an Ad Hoc build using iPhone Configuration Utility

Testers can also install your app directly from a website by clicking on a link using a web browser app from their iOS device. Although this process is sometimes referred to as “Enterprise Distribution,” you do not need to be part of the iOS Enterprise Developer Program to distribute an Ad Hoc build wirelessly. A common workflow would be to send testers an email with a link to an internal website. From there they would use the link to open up the web browser to a URL from which they can load the app onto their device.

At a high level, here are the steps required for Wireless Ad Hoc Distribution:

application/octet-stream ipa
text/xml plist

.ipa application/octet-stream
.plist text/xml

Building for Wireless Distribution

To prepare an app for Wireless Distribution, you need two things: an application archive (.ipa) signed with your Ad Hoc Distribution Provisioning Profile, and a manifest file (.plist). Follow these steps to prepare an application archive for Wireless Distribution:

1. Create an archive build of your app signed with the Ad Hoc Distribution Provisioning Profile (see Ad Hoc Build Distribution).

2. Within Xcode, open Organizer (Window menu → Organizer).

3. Go to the Archives tab and select the build you wish to distribute, press the “Distribute...” button (see Figure 5-17).

4. For the “Select the method of distribution:” dialog box, choose “Save for Enterprise or Ad-Hoc Deployment” (see Figure 5-18) and press Next.

5. For the “Choose an identity to sign with:” dialog box, select your Distribution signing certificate (see Figure 5-19) and press Next.

6. You will be prompted to save the .ipa file (see Figure 5-23). Set the following fields and press Save when done:

   1. Save As: provide a name for your .ipa file.

   2. Check the “Save for Enterprise Distribution” check box.

   3. Application URL (required field): Make sure this URL has the full path to your .ipa file. Verify the filename here matches the “Save As” setting.

   4. Title (required field): Enter a suitable title for your app.

   5. Subtitle, Large Image URL, Small Image URL, and the “Add Shine Effect to Images” fields are all optional.

7. An application archive file (.ipa) and a manifest (.plist) file will be saved to your computer.

Figure 5-23. Preparing an archive for Enterprise Distribution

<a href="itms-services://?action=download-manifest&url=http://192.168.1.106/apps/nextgreatapp.plist">Install NextGreatApp</a>

<a href="http://192.168.1.106/apps/Ad_Hoc_Distribution_Provisioning_Profile.mobileprovision">Install Ad Hoc Provisioning Profile</a>

Using the Team Agent account, log in to the iTunes Connect website (https://itunesconnect.apple.com) and follow these steps to create a record of your app. The record is what either Xcode or Application Loader will deploy the compiled binary to.

Now that your app record is created, you can click on the app icon to manage the details of your app. From here you can select “Rights and Pricing” to manage the availability date, price tier, and the countries where you wish your app to be available (see Figures 5-28 and 5-29).

Figure 5-28. Details of your app record on iTunes Connect

Figure 5-29. Setting Pricing and Store Availability

This section details how to submit an application archive to iTunes Connect through Xcode Organizer. The workflow here is not to build an App Store archive from scratch, but re-signing an existing (fully tested) build archive with the App Store Distribution Provisioning Profile. Prior to submitting your app to iTunes Connect, verify the following:

Using Xcode Organizer, you can choose to validate your app archive without actually submitting it to iTunes Connect. The validation process checks to see whether your app binary is ready to be submitted (properly signed, with correct icon files and version numbers). When you submit your app to the App Store, validation also runs and (providing validation passes), uploads your app to iTunes Connect for review. Follow these steps to validate or submit your archive to iTunes Connect using Xcode Organizer (see Figure 5-31):

Figure 5-31. Using Organizer to validate or submit your app to Apple

Figure 5-32. App Store Distribution packaging and signing options

Figure 5-33. The app was validated successfully

You can use Application Loader (installed with Xcode) to submit your app to iTunes Connect. A potential workflow here is that the app was developed by company A and the ZIP file has been given to company B, who will deploy the app using their name and credentials. Another scenario could be that you have built your app using the xcodebuild command line utility and have compressed the resulting .app directory into ZIP format for deployment (see Building for App Store Distribution with xcodebuild). The same prerequisites apply as when you are submitting an archive via Xcode Organizer (see App Store Distribution Using Xcode). Follow these steps to submit your ZIP archive to iTunes Connect using Application Loader:

Figure 5-34. Log in with your Team Agent account

Figure 5-35. Delivering your app binary to iTunes Connect

Figure 5-36. Select the application record in iTunes Connect

Figure 5-37. Your Application Information from iTunes Connect

Figure 5-38. Upload your app to iTunes Connect

Congratulations! Your application binary has been uploaded to iTunes Connect. Hopefully there will be a relatively short period of time in which your app will be reviewed, approved, and posted to the App Store by Apple. Apple does provide an online form where you can Request an Expedited App Review for your app if you have an urgent bug fix or (to quote the linked website) “are facing extenuating circumstances”.

This section covers how to update an app that you already have available on the App Store. Using the Team Agent account, log in to the iTunes Connect website (https://itunesconnect.apple.com) and follow these steps to create a new record for the next version of your app: