in iOS

Adding New Development Devices

Today I join the ranks of proud iPhone owners (maybe not so much in Japan though). Yes, it an extra expense I can barely afford, but my previous cell phone contract was pretty much over and it made sense. So far I had been doing all my development on an iPod Touch, but I could really use a real iPhone for beta testing Flower Garden with all the reports of significant performance differences between the iPod Touch 2nd gen and iPhone. Besides, with 360iDev and GDC coming up, being able to have constant internet access for email and Twitter is a huge bonus.

Or maybe I just had gadget envy. Whatever.

But I’m not writing to rub in what a cool gadget I have now. I had a couple interesting experiences adding new devices to XCode and I figured I would share them with other iPhone devs.

SDK and firmware compatibility

This is something I noticed a few weeks ago, but I was able to confirm it with my new iPhone. Each new version of the iPhone SDK warns you to upgrade your device firmware to that version before you attempt to run any programs on it with the new SDK. I always took that literally, but I realized it’s not as restrictive as it sounds.

With each version of the SDK, you have the option to target your build to that version or any of the previous ones. I discovered quite by accident that is perfectly fine to use a certain SDK (like 2.2.1) to build for an earlier version (2.0) and run it on a device with older firmware matching that version. It really makes a lot of sense, because otherwise the only way you could test your app on older firmware would be by reinstalling an old SDK. So maybe this is old news to most people, but it was certainly nice to first upgrade the SDK, and only later the firmware to minimize potential for problems.

Updating provisioning profile

So with my new shiny iPhone in hand (actually, it was a $99 refurbished model, but it shines like new and has that new car smell… oh wait), I set to run Flower Garden on it. The process involved the following steps:

  • Add a new device with the UDID of my iPhone to the Apple Developer Program account. I made the mistake of having to type it manually from iTunes–didn’t realize that XCode allows you to copy and paste it, doh!. Check.
  • Add the new device to the development provisioning profile I was using. Check.
  • Download the updated provisioning profile and add it to XCode and my iPhone. Since the iPhone was plugged, all I had to do was drag it onto XCode. Check.
  • Clean all, build, run. And….

Yeah, you guessed it, I got an error. Otherwise I wouldn’t be writing this if it had behaved as expected, would I? The error kindly informed me that the provisioning profile I was using to build the app wasn’t available on my device. But I could see it in the organizer window of XCode. I double checked it was the correct one and that Flower Garden was being built with that one. Check. Check.

What was going on?

Here’s the fun part, which took me a few minutes of digging through the docs. When I added the updated provisioning profile, XCode decided that it was a different one from the one I was trying to replace. But, here’s the kicker, they both had the same name and description. So XCode was still building my app with the old one, but it was the new one that was installed on the iPhone.

I discovered this by going to the source. XCode stores all the provisioning profiles in the folder ~/Library/MobileDevice/Provisioning Profiles. You can’t tell much of anything by looking at the filenames since they’re a bunch of UIDS, but you can crack the files open with a good text editor and you’ll see they’re a mix of text and binary data. From there, you can see which file corresponds to which profile by looking at the text between the <Name> tags. All I had to do was delete the two development provisioning profiles, re-add the new one to XCode and the iPhone and I was back in business.

I had heard so many horror stories of upgrades to 2.2.1 that I was afraid I was hitting one of those. Fortunately it was quite simple. Next time I’ll know where to look right away.

Now it’s back to work for me. I still need to finish the slides for 360iDev and then I need to fix a couple of things in Flower Garden and get it ready for the first round of beta testing. Sleep? What’s that?

  1. Yes, it is a bit of a pain. I always delete the old profile manually like you describe and also quit XCode before installing the new one. I also completely delete the build/ directory.
    As for the firmware version: It makes sense to target firmware 2.0 as far as I know. That way you don’t exclude any potential customers. Of course if you need features introduced later, you need to use a later version. But Apple has barely introduced any new features in its SDK updates so far, so most apps can target 2.0 without any problem.

  2. Actually, I’m targeting 2.2 for Flower Garden. I started using AVAudioPlayer and it’s hard to give up (it’s a 2.2 feature). I’m not too concerned though. There seem to be lots of apps in the top 20 that require 2.2 (even some of them 2.2.1 why????)

  3. I think because people don’t understand the differences between installed SDK, target SDK and firmware version. I haven’t seen an Apple document that gives good explanations and guidance on this.

  4. Thanks for the comments I was having trouble install the provisioning profile on the iPod. Deleting all of them manually while xcode was off. Then starting xcode, install the profile, and run on the iPod worked like a charm. Thanks!

  5. Hey, what you should really be doing is installing provisioning profiles manually into ~/Library/MobileDevice/Provisioning Profiles with Xcode closed, then go back into Xcode and select the new PP at the project level. This smoothes out a lot of issues because it doesn’t screw up the names of your provisioning profiles, and you can actually remember which is which.

    You’ll also want to hit delete on the target level setting for code signing identity so it just reflects the project level setting.

    Hope that helps!

  6. Hi Noel,

    Here is a little tip for when you are going to ask your beta testers to send their UDIDs. Chances are they won’t have XCode installed on their computer. Luckily, copy-paste also works from within iTunes:
    – open “Summary” tab
    – click “Serial Number” -> it will change to Identifier
    – command-C to copy (you do not have to select the text)
    et voilà, the 40 characters-long UDID is now in your clipboard!

    Here is another tip to know what provisioning profiles in ~/Library/MobileDevice/Provisioning Profiles correspond to. In XCode Organizer (Command-Control-O), there is a “PROVISIONING PROFILES” section from which you can select each profile and you’ll be able to see its corresponding mangled file name as well as some extra information (such as the number of devices in the profile, the App Identifier, …).

    I hope this helps.


  7. Thanks, Ramses. I didn’t know you could copy the UDID from iTunes since you can’t highlight it! What a horrible interface, but that’s great to know. Thanks!

  8. Thanks for the information. You saved me a bunch of time. I could make an addition:
    In the Xcode organizer, there is a ‘iPhone Development -> Provisioning Profiles’ section. After updating and then adding the updated profile to your device, you will see two profiles in the this section. One of them is old, the other one is the new updated one. If you delete the old one, everything is gonna be all right. 🙂

  9. In addition to the iTunes copy workaround, there’s also a free app “BetaHelper” which grabs the UDID (+OS etc) and emails it to the destination of your choice. Perfect when you’re feeling too lazy to go to the desktop. 😉

Comments are closed.


  • iPhone Developer Program Gotchas July 30, 2009

    […] 6. Adding provisioning profiles. Forget about dragging them on XCode and manage them manually. Check out my earlier entry about it. […]