Creating ad-hoc distribution profiles

The instructions that Apple provides are here, but here is how I created a general provisioning profile that will work with multiple apps, and added a beta tester.

My setup:

• Xcode 3.2.1
• iPhone SDK 3.1.3

Before you get started, make sure that..

• You can run the app on your own iPhone through Xcode.

Step A: Add devices to the Provisioning Portal

1. Send an email to each beta tester with the following message:

   To get my app on onto your iPhone I need some information about your phone. Guess what, there is an app for that!

   Click on the below link and install and then run the app.

   http://itunes.apple.com/app/ad-hoc-helper/id285691333?mt=8

   This app will create an email. Please send it to me.

2. Collect all the UDIDs from your testers.

3. Go to the Provisioning Portal.

4. Go to the section Devices.

5. Click on the button Add Devices and add the devices previously collected.

Step B: Create a new provisioning profile

1. Start the Mac OS utility program Keychain Access.

2. In its main menu, select Keychain Access / Certificate Assistant / Request a Certificate From a Certificate Authority...

3. The dialog that pops up should aready have your email and name it it.

4. Select the radio button Saved to disk and Continue.

5. Save the file to disk.

6. Go back to the Provisioning Portal.

7. Go to the section Certificates.

8. Go to the tab Distribution.

9. Click the button Request Certificate.

10. Upload the file you created with Keychain Access: CertificateSigningRequest.certSigningRequest.

11. Click the button Aprove.

12. Refresh your browser until the status reads Issued.

13. Click the Download button and save the file distribution_identify.cer.

14. Doubleclick the file to add it to the Keychain.

15. Backup the certificate by selecting its private key and the File / Export Items....

16. Go back to the Provisioning Portal again.

17. Go to the section Provisioning.

18. Go to the tab Distribution.

19. Click the button New Profile.

20. Select the radio button Ad hoc.

21. Enter a profile name, I named mine Evertsson Common Ad Hoc.

22. Select the app id. I have a common app id to use for multiple apps: Evertsson Common.

23. Select the devices, in my case my own and my tester's.

24. Submit.

25. Refresh the browser until the status field reads Active.

26. Click the button Download and save the file to disk.

27. Doubleclick the file to add it to Xcode.

Step C: Build the app for distribution

1. Open your project in Xcode.

2. Open the Project Info pane: In Groups & Files select the topmost item and press Cmd+I.

3. Go to the tab Configuration.

4. Select the configuration Release.

5. Click the button Duplicate and name it Distribution.

6. Close the Project Info pane.

7. Open the Target Info pane: In Groups & Files expand Targets, select your target and press Cmd+I.

8. Go to the tab Build.

9. Select the Configuration named Distribution.

10. Find the section Code Signing.

11. Set the value of Code Signing Identity / Any iPhone OS Device to iPhone Distribution.

12. Close the Target Info pane.

13. In the main window select the Active Configuration to Distribution.

14. Create a new file from the file template Code Signing / Entitlements.

15. Name it Entitlements.plist.

16. In this file, uncheck the checkbox get-task-allow.

17. Bring up the Target Info pane, and find the section Code Signing again.

18. After Code Signing Entitlements enter the file name Entitlements.plist.

19. Save, clean, and build the project.

20. In Groups & Files find the folder MyApp / Products and expand it.

21. Right click the app and select Reveal in Finder.

22. Zip the .app file and the .mobileprovision file and send the archive to your tester.

    Here is my app. To install it onto your phone:

    1. Unzip the archive file.

    2. Open iTunes.

    3. Drag both files into iTunes and drop them on the Library group.

    4. Sync your phone to install the app.

Done! Phew. This worked for me. So far I've only added one tester.

status: this has been seen as recently as Mac OS 10.8 and Xcode 4.4.

tl;dr: This can occur in two contexts: when running on the device and when running on the simulator. When running on the device, disconnecting and reconnecting the device seems to fix things.

Mike Ash suggested

launchctl list|grep UIKitApplication|awk '{print $3}'|xargs launchctl remove

This doesn't work all the time. In fact, it's never worked for me but it clearly works in some cases. Just don't know which cases. So it's worth trying.

Otherwise, the only known way to fix this is to restart the user launchd. Rebooting will do that but there is a less drastic/faster way. You'll need to create another admin user, but you only have to do that once. When things wedge, log out as yourself, log in as that user, and kill the launchd that belongs to your main user, e.g.,

sudo kill -9 `ps aux | egrep 'user_id .*[0-9] /sbin/launchd' | awk '{print $2}'`

substituting your main user name for user_id. Logging in again as your normal user gets you back to a sane state. Kinda painful, but less so than a full reboot.

details:

This has started happening more often with Lion/Xcode 4.2. (Personally, I never saw it before that combination.)

The bug seems to be in launchd, which inherits the app process as a child when the debugger stops debugging it without killing it. This is usually signaled by the app becoming a zombie, having a process status of Z in ps.

The core issue appears to be in the bootstrap name server which is implemented in launchd. This (to the extent I understand it) maps app ids to mach ports. When the bug is triggered, the app dies but doesn't get cleaned out of the bootstrap server's name server map and as result, the bootstrap server refuses to allow another instance of the app to be registered under the same name.

It was hoped (see the comments) that forcing launchd to wait() for the zombie would fix things but it doesn't. It's not the zombie status that's the core problem (which is why some zombies are benign) but the bootstrap name server and there's no known way to clear this short of killing launchd.

It looks like the bug is triggered by something bad between Xcode, gdb, and the user launchd. I just repeated the wedge by running an app in the iphone simulator, having it stopped within gdb, and then doing a build and run to the ipad simulator. It seems to be sensitive to switching simulators (iOS 4.3/iOS 5, iPad/iPhone). It doesn't happen all the time but fairly frequently when I'm switching simulators a lot.

Killing launchd while you're logged in will screw up your session. Logging out and logging back in doesn't kill the user launchd; OS X keeps the existing process around. A reboot will fix things, but that's painful. The instructions above are faster.

I've submitted a bug to Apple, FWIW. rdar://10330930