I recently had to revisit my process for distributing applications over the air and since the process has changed slightly since Xcode v3 it seemed like a good idea to document it publicly in the event anyone else gets some benefit from it.
The big change from XCode 3 is you no longer need to fart with the entitlements.plist file and it's associated keys (get-task-allow, application-identifier etc). XCode automatically set's these during the build process.
I'm assuming you have your Public/Private Certificates setup already, including the WWDR certificates provided by Apple. If not refer the to documentation in the Portal and use KeyChain to make that happen.
There are basically 4 key parts to providing a version of your application for easy install/distribution via a web server:
- Setup the Provisioning Profiles
- Configure the Schemes and Targets
- Creating the Archive
- Configuring the Website
Setup the Provisioning Profiles
In order for your application to be installed on an end users device you need to gather their UDID and add it to the correct provisioning profile. There are lots of ways of doing this, but my preferred way is to ask the user to connect their device and run iTunes.
iTunes provides a hidden mechanism for displaying the UDID. Attach the device and select the Summary tab for the selected device, then click on the Serial number field, which should change to display 'Identifier'. Have your users select and send this number to you.
Once you have the UDID's open your developer Portal and select Devices (top left). Here you can either paste the UDID's in one at a time or import them from a file. Select either 'Add Device' or 'Upload Devices' and enter your user's UDID's.
Once complete this will make those devices 'selectable' when you are creating/editing the provisioning profile.
The next step is to create an Application ID. This ties the Profile and Applications you create for those devices in the profile together. This is done by selecting 'App IDs' from the menu on the left and choosing 'New App ID'.
Give the App ID a very descriptive name so you can remember how it's connected to your applications.
Leave the Seed as 'Team ID' and use the suggested method of reverse domain name for the suffix (the part of the application identifier after the randomly generated characters).
I prefer to use WildCards for my Bundle ID's as I find it cleaner in XCode, especially if I'm managing multiple products and versions; but each to their own. To set a wildcard App ID, simply put an asterisk at the end of the bundle identifier.
You should end up with something like 'XXXXXXXXX.com.companyname.*'.
From here we need to select Provisioning and then 'Distribution' from the top row of tabs (the default is 'Developer'). Select an existing Distribution profile or click 'New Profile'.
Select 'Ad Hoc' as the distribution method - this is a very important step. Now give the profile a name. I prefer to be very explicit when naming my profiles to make it really obvious in XCode and during the Archive process which profile I'm using. I prefer names such as 'Ad-Hoc Distribution Profile for Application XXXXXX' or 'AdHoc Distribution Profile for Test Group 1 on version 1.0.5'.
This process is now connecting the distribution certificate with the devices for specific application(s).
Once the profile is named you need to configure the profile to allow an application(s) to use it. At this point we are connecting the bundle ID (App ID) with the profile with the certificate with the devices in the profile.
Now select the devices that you want your release to be made available to. Click the Submit button.
You will notice that the page will show 'Pending' for this profile. This process generally takes about 5 seconds to generate, I normally wait the 5 seconds and click the 'Distribution' link at the top again. Once completed the provisioning profile will show a 'Download' link.
Click to download the Provisioning profile.
Now we need to get this into profile into XCode. Open XCode and select the Organizer from the Window menu (CMD+SHIFT+2). Pick the 'Devices' section and select from the top left the 'Provisioning Profiles' link.
Navigate back to finder and open the folder that you downloaded the profile into. Select and drag the provisioning profile from the finder window into the Provisioning Profiles section in the Organizer.
Xcode will attempt to validate the profile to ensure you are allowed to use it and that it came from your dev account etc, which means you will most likely be prompted for you Apple Dev Account ID and it's password. Plug those credentials in and let it do the validation.
Once validated the provisioning profile should show a green tick. If it doesnt the most likely culprit will be your Private Key isn't setup correctly.
So far we have created our distribution provisioning profile, set the devices we want it to be made applicable to, specified the all important Bundle Identifier, downloaded and installed the profile into Xcode. We are now ready to setup Xcode to make use of our newly installed friend.
Configuring the Schemes and Targets
Coming from the land of .Net and having a very simplistic build configuration I was initially confused by the terms Scheme, Target and Configuration. It wasn't until I used a third party library that leveraged all three did I realise how powerful XCode really is (truth is I HAD to learn).
If I get my explanation wrong please forgive me, I'm learning too, but in my head it seems right, so there
Think of the Scheme as the parent container for the Target and Configuration. The scheme controls what is built and what type of stuff is built depending on the action you take in Xcode. There are built in Schemes (corresponding to Xcode actions) for Build, Run, Test, Profile, Analyze and Archive. Each scheme points to a specific configuration inside the Target that is being built (for example Build, Run and Test are all using the Debug Configuration).
I imagine this to be the same as saying 'I'm going to build this part of the app' or 'I'm going to build just the static library' or 'I want to build the entire application but include the debug symbols'. Basically the target is the grouping of settings and compiler directives for the output type you select.
Each Target can have multiple configurations. By default you are given 'Release' and 'Debug', but you can clone these or create them from scratch to suit your needs. Remeber that each scheme can point to a specific configuration inside the Target so when you select the Scheme you are basically saying 'For whichever Target I pick to build, use these bunch of settings'.
So why is this important? It's important because you need to setup and create all three of them in order to get the correct output.
Stay tuned for Part Two: Creating the Archive...