- Creating New Projects
- Building Hello World the Template Way
- Using the Simulator
- The Minimalist Hello World
- Converting Interface Builder Files to Their Objective-C Equivalents
- Using the Debugger
- Memory Management
- Recipe: Using Instruments to Detect Leaks
- Recipe: Using Instruments to Monitor Cached Object Allocations
- Analyzing Your Code
- Building for the iOS Device
- Detecting Simulator Builds with Compile-Time Checks
- Performing Runtime Compatibility Checks
- Pragma Marks
- Preparing for Distribution
- Over-the-Air Ad Hoc Distribution
- Submitting to the App Store
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Preparing for Distribution
Building for distribution means creating a version of your application that can be submitted to Apple for sale in the App Store. Before you begin submitting, know how to clean up builds, how to edit and use schemes, and how to create an archive of your application. You want to compile for the App Store with precision. Cleaning first, then compiling for distribution helps ensure that your applications will upload properly. Archiving produces an application bundling that can be shared and submitted. The section covers these skills and others used with distribution compiles.
Locating and Cleaning Builds
Xcode 4 uses a new approach to build code and store built products. In Xcode 3, compiled code was added to a “build” subfolder in your project folder. In Xcode 4, applications are created in your home library by default, in ~/Library/Developer/Xcode/DerivedData. You can locate the built product by selecting it in Project Navigator in the Products group. Right-click the application and choose Show in Finder. Project Archives, which are used for building products that are shared with others or submitted to the App Store, are stored in ~/Library/Developer/Xcode/Archives.
Cleaning your builds forces every part of your project to be recompiled from scratch. Performing a clean operation also ensures that your project build contains current versions of your project assets, including images and sounds. You can force a clean by choosing Product > Clean (Command-Shift-K).
Apple recommends cleaning before compiling any application for App Store review, and it’s a good habit to get into.
Using Schemes and Actions
In Xcode, schemes store project build settings. They specify what targets to build, what configuration options to apply, and how the executable environment will be set up. Actions are individual tasks that you can perform to create builds as well as to test, profile, analyze, and archive your application.
Each scheme consists of a project and a destination. Figure 3-24 shows the scheme pop-up for the Hello World project from this chapter. Access this pop-up by selecting Hello World to the right of the Run button. This is a funny kind of pop-up in that it’s actually split. Clicking to the left or the right of the embedded chevron provides two slightly different menus.
){kind=link}
Figure 3-24. The scheme pop-up menu consists of schemes and their run destinations, followed by management options.
Clicking the left produces the pop-up shown in Figure 3-24. This pop-up includes a list of schemes (just one here) and their possible run destinations. Here, destinations include the device and four simulator styles (iPhone and iPad, for iOS 4.3 and iOS 5.0). Following the scheme list is a menu line followed by three options to edit, create, and manage schemes.
Clicking the right shows only the destination submenu, allowing you to pick a destination for the current scheme. Destinations include any provisioned and development-enabled iOS devices as well as all possible simulator choices for your deployment build settings.
With your scheme selected, choose Edit Scheme from the pop-up menu to see a list of available actions. Figure 3-25 shows the actions associated with the Hello World scheme from Figure 3-24. Each action represents an individual development task. They include the following:
){kind=link}
- Build—Building the code
- Run—Running the compiled code on a device or in the simulator
- Test—Using Xcode unit test tools that help stress application features
- Profile—Running the code with live sampling using Instruments
- Analyze—Applying the static analyzer to unresolved issues
- Archive—Preparing the application for sharing or submission to the App Store
)
Figure 3-25. The actions list for a scheme offer a set of tasks that may need to be performed during the creation of an application.
Use this scheme editor to customize how each action works in Xcode. For example, in the Run action shown in Figure 3-25, the debugger is set to LLDB. You can easily change this to GDB by selecting it from the pop-up.
You’ve already seen the action menu in the Instruments walkthrough earlier in this chapter. Access it by clicking and holding the Run menu at the top-left corner of the Xcode window. Select the action you want to perform from the pop-up. The Run button updates to show the new action item.
Adding Build Configurations
Build configurations allow you to specify how your application should be built. They act as a quick reference to the way you want to have everything set up, so you can be ready to compile for your device or for the App Store just by selecting a configuration. They also are useful for adding instrumentation and conditional compilation. Standard Xcode projects offer Debug and Release configurations. You may want to create a few others, such as one for ad hoc distribution.
Configurations are created and managed on the PROJECT > project name > Info screen in the Configurations section (see Figure 3-26). Assuming you’ve been following along in this chapter, you have already set up the HelloWorld project and edited its debug build settings. It uses your team wildcard provision to sign the application. Instead of editing the build settings each time you want to switch the signing provision, you can create a new configuration instead. Typical configuration options include which architectures you wish to build for and your default code-signing identity.
){kind=link}
)
Figure 3-26. Use the Info > Configurations pane to create new configurations so you can build with preset options such as signing identities.
In the following sections, you’ll read about adding an ad hoc configuration to your project. This is really for example purposes only—because I cannot really think of many other ways you’d want to change build settings for ad hoc versus App Store and because you can pick your signing identity in the Organizer when creating bundles for both destinations. Adapt this example and its steps for your real-world requirements.
About Ad Hoc Distribution
Apple allows you to distribute your applications outside the App Store via ad hoc distribution. With ad hoc, you can send your applications to up to 100 registered devices and run those applications using a special kind of mobile provision that allows the applications to execute under the iPhone’s FairPlay restrictions. Ad hoc distribution is especially useful for beta testing and for submitting review applications to news sites and magazines.
The ad hoc process starts with registering devices. Use the iPhone Developer Program portal to add device identifiers (Program Portal, Devices) and names to your account. Recover these identifiers from the iPhone directly (use the UIDevice class), from Xcode’s Organizer (copy the identifier from the overview tab), from iTunes (click on Serial Number in the iPhone’s Summary tab), or via the free Ad Hoc Helper application available from iTunes. Enter the identifier and a unique username.
To create a new ad hoc configuration, create a new provision at the iOS portal. Select Program Portal > Provisioning > Distribution. Click Add Profile. Select Ad Hoc, enter a profile name, your standard wildcard application identifier (for example, com.yourname.*), and select the device or devices to deploy on. Don’t forget to check your identity and then click Submit and wait for Apple to build the new mobile provision. Download the provision file and drop it onto the Xcode application icon.
With your new provision on hand, duplicate the Release configuration. Xcode creates a copy and opens a text entry field for its name. Edit the name from Release copy to Ad Hoc.
Next, click the Build Settings tab and locate the Code Signing section. Assign your new ad hoc provision to your ad hoc configuration. Use the pop-up to the right of Any iOS SDK. The selected provision then appears in the Code Signing Identity list, as shown in Figure 3-27.
){kind=link}
)
Figure 3-27. New configurations appear separately in the Code Signing section of your build settings.
To finish, choose your new build configuration in the Archive action section of the Scheme editor.
Building Ad Hoc Packages
When you’re ready to share your app with members of your ad hoc list, follow these steps:
- If you wish to use a custom compiler scheme, choose Edit Scheme from the Scheme pop-up at the top of the Xcode window. Select Archive and set your Build Configuration as desired. Click OK. If you want to use the default compiler scheme, you may skip this step.
- Choose Product > Archive from the main Xcode menu.
- Wait for Xcode to work. The Organizer will open when it is finished, displaying the Archives tab. This screen allows you to review, manage, and use archived copies of your applications. You can also add free-form comments to each archive—a very handy feature—and a status line lets you track when archives have been successfully submitted to the App Store.
- For ad hoc distribution, click Share. Choose iOS App Store Package (.ipa) as your destination.
- Choose your ad hoc provision from the Identity pop-up and click Next.
- Specify the name of your new package (for example, HelloApp) and where to save it. Click Save.
After following these steps, you can now e-mail the newly built .ipa file to members of your beta list or post it to a central site for download.
The .ipa bundle you built is actually a renamed ZIP file. If you extract it and look inside the Payload folder, you’ll discover the compiled application bundle. This contains an embedded mobile provision that enumerates all the device IDs included in the ad hoc provisioning.
<string>Wildcard Ad Hoc </string> <key>ProvisionedDevices</key>