Assuming you have finished the process of signing up for the paid developer program, you are now authorized to load applications such as the “Hello World” example onto an iPhone using Xcode. However, you have to jump through a couple more hoops before you can do this.
Since the iPhone is a secured platform, a lot of bookkeeping is required before you can execute your code on the device. You have to sign builds, Apple has to trust your signature, and the device you are loading has to be provisioned for self-signed applications.
You manage signatures, certificates, and provisioning profiles through the online Program Portal on Apple’s website. Once you are a paid developer, you can find it at http://developer.apple.com/iphone/manage/overview/index.action.
The portal has step-by-step guides for each section—generating Certificate Signing Requests (CSRs), creating a distribution profile, adding a device ID, and so on. However, this can be a complex process, so we will go over the general concepts.
To publish your application to a phone or to the App Store, you need two signed profiles. One is a developer profile, which you use while developing and testing your app. The other is a distribution profile, which you use when sending your finished application off to the App Store to be published. In a corporate setting, the lead programmer might keep track of the developer profile, whereas the production manager might keep track of the distribution profile.
To create these profiles, you need to generate a certificate that has a public and private key. Apple has to sign the certificate for it to be valid, so first you must use Keychain Access on your Mac to create what is called a Certificate Submission Request, which gets sent to Apple’s developer program. When Apple has reviewed and approved your request, you can download the certificate from the Apple Developer Portal website.
Once you have the signed certificate, you will need an Application Identifier (App ID), a Unique Device Identifier (UDID), and the WWDR certificate.
The App ID is generated on the Developer Portal to be used in a
profile and in your application bundle. An App ID looks like this:
com.YourGameCo.YourAwesomeGameName.
This is called reverse domain notation, and Java and C# programmers may be familiar with it as the
format that package names use in those languages.
If you will be making multiple applications, you can use a
wildcard format so that the same developer can use one App ID for
multiple applications. A wildcard App ID looks like this: com.YourGameCo.*.
When listed in the Developer Portal, the ID may have 10 alphanumeric characters appended to the front. These are for Apple’s internal use and you can ignore them.
After creating an App ID on the Developer Portal, you must open the Info.plist file in your application bundle and replace the default value of the bundle identifier key with your App ID. If you used a wildcard when creating the App ID on the Portal, you should also replace the asterisk (*) with the name of your game when updating the Info.plist file.
The UDID is a 40-character hex string that you can obtain from the iPhone device you wish to load by attaching it to your Mac and running iTunes or the Xcode Organizer window.
Note
The UDID is used only for the developer profile and is not useful for the distribution profile.
Apple’s World Wide Developer Relations (WWDR) certificate is available from Apple at http://developer.apple.com/certificationauthority/AppleWWDRCA.cer. Download and install the certificate so that you can use it to certify builds. The WWDR certificate links your development certificate to Apple, completing the trust chain for your application.
Once you have these three items, you can download a provisioning profile from the Developer Portal. This file will have a .mobileprovision file extension. Once you download this file, double-click it to install the profile. It should load into Xcode’s Organizer and show up there when you connect your iPhone to your computer. Make sure the profile is listed in the device’s installed profiles.
Keep in mind that an application is limited to the devices listed in its developer profile.
Once you have all the certificates, keys, and profiles installed, you are ready to set up Xcode to compile an application that will run on your iPhone.
Set the code signing profile in Project→Edit Project Settings→Build→Code Signing Identity→Any iPhone OS Device. See Figure 1-21.
If your provisioning profile does not show up in the drop-down list, you are missing some part of the certificate chain:
Private key
Signing certificate
WWDR certificate
Provisioning profile
Change the bundle identifier to match the App ID name in the provisioning profile. Select the Build Clean menu option after any Info.plist changes; otherwise, the changes will not be reflected in the build (see Figure 1-22).
Set Xcode to build for the device, as shown in Figure 1-23.
If everything goes smoothly, you should be able to build and run the application on the device. Xcode will install your app on the device during the build process.
If something goes wrong, you won’t see any helpful error messages; you will see “ApplicationVerificationFailed,” which could mean anything went wrong. Here is a list of some common issues that could be the source of an error:
- The bundle identifier contains typos or whitespace
The bundle identifier must match the App ID. You must select Build→Clean after modifying the bundle identifier.
- Part of the certificate chain is missing
The WWDR certificate is easy to miss.
- Your certificate has expired
If everything has been working fine and you suddenly encounter a problem as you get closer to your deadline, you may have an expired certificate.
Sometimes just rebooting the iPhone and reconnecting it will get things back on track.
Get iPhone Game Development now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
