If anyone would like the sample project I can upload those also.

Data Access Presentation

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:

1. Setup the Provisioning Profiles
2. Configure the Schemes and Targets
3. Creating the Archive
4. 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.*'.

Provisioning Profile

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

Scheme

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).

Target

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.

Configuration

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...

Check it out even just for a look se:

http://developer.yahoo.com/cocktails/mojito/docs/intro/mojito_quicktour.html

The problem comes about when you upload a single package to iTunes Connect with both binaries;

1. I can't set separate prices for each binary (iPhone/iPad)
2. It's not clear that when a sale is made of the universal that it's because they wanted it on the phone or for the iPad
3. There's no way to release different versions separately, if you update the iPad code it automatically updates the codebase for the iPhone.

The first reason I would wont two products is simple - the iPad is my primary market and hence I'll be devoting significantly more resources on this platform (mostly because of screen size affords me the ability to create a much more simplified UI) and therefore I feel I can warrant a slightly higher price tag.

There are simply some things a larger screen size lets you do that the iPhones' screen cannot - the Landing Soon dashboards are a perfect example.

On the second point regarding "who's downloading what" - if I knew that people are buying the iPhone app over the iPad version then I'd have to rethink my allocation of effort.

Until this afternoon when someone suggested I use two build targets and restructure my build process I wouldn't have even thought it possible to get two separate products from the same code base - so that's what I'll be doing over the next week...

The iPhone version will most likely be a whole dollar cheaper than the iPad version but will contain most (80%) of the feature set.

Stay tuned for many exciting new features in the coming months - including an iPhone version.

As usual we LOVE feedback.

I had originally planned a much larger feature set for the first release but after reading two Agile/Scrum articles I decided to stick with the philosophy 'release early, release often'.

As much as I like WordPress (and I do) I ditched my previous installation and hand coded the Landing Soon website - www.landingsoonapp.com