I'm attempting to do an ad-hoc distribution of my (first) iPhone App to a small group of volunteer testers. I've looked through Apple's documentation, as well as a number of blog posts, but am still having trouble. I have a couple questions about things that aren't clear (to me, at least):
When creating Development and/or Distribution certificate requests, for Common Name, should I use my name or my company's name? I registered for the iPhone Developer program as a company, and the portal shows this company name, but also my own name as "Agent".
Also, Apple's documentation (the "Publishing Applications for Testing" chapter of the Developer's Guide) contains a diagram showing the Tester Provisioning Profile as containing info about the Tester Device, the Test App ID, and the Development Certificate. When I try to create the Tester (Ad-hoc) Provisioning Profile on the portal, it selects the Distribution Certificate, not the Development Certificate. Is this right? It seems to make sense, but doesn't match the diagram.
Any other advice on ad-hoc provisioning would also be appreciated, particularly how to gather information for troubleshooting. My testers have reported getting an "application was not installed because an unknown error occurred (0xE8008016)" message, which doesn't tell me anything about what I may have done wrong.
Thanks,
Andrew
Well, I seem to have it working -- sorry for the long delay in following up. Here's the best resource on this that I've found: http://www.bigspaceship.com/blog/labs/iphone-101-understanding-distribution-pt-i-of-ii/ although even it doesn't get quite all the details right, and it seem that Apple changes the iPhone Program portal often, so maybe no resource will ever be fully up-to-date. Your mileage may vary.
To answer the questions I posed (and reply to some of the questions raised in other answers): For the Developer Certificate, I used my own name. For the distribution certificate, I used the name of the Company. Yes, the dist.plist bust exist and the get-task-allow property is false.
Finally, one more gotcha: the AppID/Bundle identifier should be all-lowercase.
I posted a sample packaging script that i use for automating ad hoc distribution builds, maybe this is useful?
http://iphonedev.makerlab.org/2009/12/packaging-script-for-iphone-ad-hoc-distribution-builds/
I used my own name for Common Name, however, I'm not sure this really matters. I did name my dist. provisioning profile with my company name, though.
Ad-Hoc is considered distribution, so the distribution certificate is the correct one.
Did you create an Entitlements.plist file for your ad-hoc?
Are you getting any signing errors when you build your ad-hoc?
Does the ad-hoc build you created install properly for you? That's the easiest way to gather information-try it yourself, following the directions you're giving your users.
I had problems with Windows users not being able to install my app because Windows couldn't properly decode the compressed folder I created on my Mac. I eventually resorted to a Run Script build phase in XCode that created a .ipa file which worked properly for drag-and-drop for Windows and Mac iTunes.
In your entitlements.plist file you have to uncheck the get-task-allow bool to give it a false value. This is only for AdHoc distribution.
I learned this the hard way when I went through a build cycle thinking I had saved and checked in the right entitlements.plist with get-task-allow unchecked.
Related
Over the past couple of days I've worked my way through all the prior posts on here that I could find that seemed to be related (many of them appear to be horrifically out of date and less than useful now), as well as the Apple Troubleshooting and Maintaining Your Signing Identities and Certificate guides (not to mention the usual Internet searches).
The app in question was deploying fine until the latest XCode update, but now fails to upload (build is successful obviously, and there have been code changes as well):
ERROR ITMS-90161: "Invalid Provisioning Profile. The provisioning profile included in the bundle *content removed* is invalid. [Missing code-signing certificate]. A Distribution Provisioning profile should be used when submitting apps to the App Store. For more information, visit the iOS Developer Portal."
It's not the first time I've mysteriously had a failure like this, but in prior cases simply revoking the certs, removing the profile, then rebuilding would take care of it. Not so in this case.
The provisioning profile is confirmed to be the correct type, and the code signing certificate sure looks like it's in there... Certificate gets a nice green checkmark too. Any new suggestions not covered in the usual places?
It turns out that there's nothing wrong with the certificate itself, but it's the upload process which needs to be done different.
In the past I had been deploying the distribution outputs from Cordova CLI via the Application Loader. The App store no longer accepts my builds when done that way.
With the current version of XCode, I need to use the GUI now and set the build target to "Generic iOS Device" and then do an "Archive" operation. The archive will upload the app through a different loader, which the App store will accept.
Right now I'm just trying to test my app on my phone and not deploy to the store.
How are all these things related? Since I'm not trying to upload to the store, can I ignore any of them?
I'm on the University Developer program. I was able to get a certificate and install it in Xcode, but builds still fail.
Is solving this problem just a matter of changing the application identifier? How do I know what to put in?
One thing I noticed is that in the Developer Portal I see only one App ID but it's for someone with a different name. So I guess I don't have an App ID. Do I need one if I'm just trying to test on my phone? If I need one, then how do I get it?
Help! It seems the more I research these things the more confused I get. If you can't solve my problem, can you at least tell me how these things are related to each other?
Provision Profiles are a very long, unique, string that allows the device to recognize certificates (very VERY helpful for development).
You must provision your device with the specific bundle ID of your app (done through developer.apple.com), then install said profile in order to even think about building with a valid certificate. However, it is much easier to have Xcode generate a wildcard provisioning profile, which allows you to test ANY bundle ID (it shows up as *.mobileprovision).
Certificates are the other side of the coin. A certificate for anything (website, application) indicates that this service can be trusted by the user, and more importantly, the OS. Certificates are issued by Apple California, are valid for a year, and may be revoked at any time for any reason. On a closed and secure platform like the iPhone, a certificate is a must for any application.
Grepping around, I see that I'm not AT ALL alone in being... challenged... by the process of setting up an iPhone app, getting it to run, giving it my testers, and so on.
I've gotten it to work. Somehow I emailed a copy or two to testers, and eventually got my li'l app into the store, and that was fine.
But I can't say a really, deeply understand it! (And I don't do iOS dev every day. Even now my recollection of what I did is kind-of hazy.)
I'm moderately capable of understanding things, if presented, well, you know, in a way I can understand.
Can anyone point me to a crystal clear explanation of what provisioning actually is?
I feel that if I understood it, the recipes to do it would be obvious.
Thanks!
Development provisioning profiles sign your application, and allow the phone to know it's OK to run. These days, XCode automatically makes a Development Profile for you (the "Team Profile").
The other kind of profile, when you are talking about other people running you app, is a Distribution Profile. You need a Distribution profile for either giving your app to the store, or for giving to beta-testers.
The profile is what allows other people's phones to know it's OK to run your app, basically it includes a list of device ID's approved to run that application on the phone in question, along with being signed so that the phone knows the whole thing is valid.
If you read advice around the web concerning distribution, it's easy to get confused because things used to be a lot harder. You used to have to send Distribution certificates separately from your app to beta testers. These days the certificates are included in your app bundle so you don't have to worry about that.
Furthermore, sending an AdHoc build can be all kinds of unpleasant - for testers using Windows. These days, the absolute best way to do beta testing is have a link on the web that uses the Enterprise ad-hoc deployment feature, to let a user with iOS4 or higher automatically download and install your application with no iTunes or copying work at all. In fact I would at this point refuse to use beta testers running windows who were not on iOS4 or higher.
The guide link posted should have a section about the enterprise ad-hoc, but basically the way it works is there's a small plist file the phone downloads, that has a link to the IPA file containing your app. You point the phone to a specially formatted link to the plist file and the phone fetches the application directly.
All of this is predicated on using the "Build and Archive" option for building any ad-hoc distribution build. You should do that anyway because it also saves out a symbol file for you to use in debugging crash reports.
EDIT:
Here's a little more detail on enterprise deployment (which works for any registered developer, not just Enterprise registered developers):
http://jeffreysambells.com/posts/2010/06/22/ios-wireless-app-distribution/
The Developer Program User Guide should be helpful.
I really combed this site and others. I read and re-read the related links here and the Apple docs. I'm sorry, but either I am obviously missing something right under my nose, or this Apple profile/certificate stuff is a bit convoluted. Here it is:
I have a product in the App Store.
I have updated it several times and users like it.
My development profile recently expired just when I was improving the app for its next release.
I can run the app in the simulator.
I can compile and put the distribution build on my iPhone just fine.
I went to the Apple portal and renewed the development profile.
I downloaded it and installed it in Xcode.
I see it in the Organize window.
I see it on my iPhone.
I CANNOT put the debug build on my iPhone to debug or run with Instruments. The message is that either there is not a valid signed profile or it is untrusted.
I subsequently tried to download and install the certificate to my Mac's keychain.
Still no success.
I checked the code signing section of Project settings and also for the target and the root. All appears to indicate that it is using the expected development profile for debug.
Yes, I had deleted the old profile from my iPhone, from the Organizer. I cleaned the Xcode cache and all targets. I have done all of this several times and in varying sequences to try to cover every possibility.
I am ready to do anything to be able to debug with Instruments in order to check for leaks or high memory usage. Even though the distribution compile runs fine on my iPhone and plays well with other running processes, I will not release anything without a leaks/memory test.
Any ideas will be appreciated. If I missed something obvious, please forgive me - it was not due to just posting a question without searching for similar postings.
Thanks!
All problems solved! I am very happy this all happened because I learned so much about Xcode, keychains, certs and provisioning. Unfortunately, there is not a simple answer. Here are the highlights:
I needed to recreate the ad-hoc profile and install it on my device. (That was MY BIG oversight and the reason the dist build no longer ran on my device.)
Between the very first time I created my profiles and the date my development profile expired, I upgraded to the 3.1.3 Xcode SDK.
It seems that this now means you need 2 entitlements files; a debug version with the get-task-allow checked and a distribution version with get-task-allow unchecked. Each need to be set in the respective settings.
In Project settings, I needed to set both my working directory and intermediate directory to the build product directory.
BIGGIE - I had to double click on the target and reset the appropriate code signing profile. There was an old profile name still there for some reason! Now, I can debug, and drop my distribution on my device without a hitch.
So, in summary, I believe that my original problem (not being able to debug after renewing my dev profile) and the problem that resulted from all my efforts to fix the first were caused by:
the fact that I upgraded to 3.1.3 during my dev cycle
my own oversight (I apologize to Apple for my criticism)
an Xcode quirk (the old profile name hanging around in target settings).
I hope this helps others. The best advise I can give is to take a day off and then create a new empty project, going through the same process step by step.
Thank you all!!
Try re-creating your development mobileprovision file on Apple's site. Be sure to delete all old copies from Organizer (including those on the iPhone itself).
So we all need to deploy our applications to real iPhones for testing purposes. I'm sure you much like me have found a group of sucke^H^H^H^H^H testers to help you out with this process. Whenever you want to send a build out to a new person this requires adding the new device id to your ad hoc provision. This part is fairly painless. The trouble starts when trying to get Xcode to use the new provision file.
Whats the best way to get Xcode to pickup and use the new provision first time? Ideally I would like to do this without changing the .xcodeproj file.
I've done this as follows, with good success:
Send out call for beta testers.
Respond to each with "in order to beta test, I need your UDID. You can send it to my by following these instructions..."
Folks incapable of sending UDID are told "thank you for your time, but beta is no longer taking applications."
If too many people can't figure it out, review your instructions.
After several days, make a batch provision file with all the people in beta.
I name the devices after the person's email address, i.e., mikeATexampleDOTcom.
I name the provision after the beta program, i.e., Neko-beta-1.
Build the app, provision & deliver (with non-technical installation instructions!)
For stragglers, you can either build another provision, or add them to the existing one, or tell them "beta's full."
Then...
After a few days, send email asking how its going, if they have any difficulties, etc.
~3 days before end of Beta, email saying "beta is coming to a close, please be sure to return your questionaires."
After close of beta, be sure to thank everyone, even those who did not reply.
How to automatically build an IPA file from XCode: http://www.idotcom.us/2009/05/how-to-build-a-ipa-file-from-xcode/
Step-by-step explanation of how to build an IPA file to send out via ad-hoc. You do have to change your XCode project but this way you create a separate target so it doesn't affect your main project.
What I do now is create a new provisioning profile if the devices change. Even if you modify an existing one, it is essentially a new profile with a different ID, but a new name. Then testers' iPhone fill up with provisioning profiles with the same name :)
Yes, it means changing your Xcode project file each time, but in my experience it's more reliable.
If you do keep the same name, beware of Xcode's cache of provisioning profiles, which can create a mess with builds. Your best bet is to remove of all the provisioning profiles from the Organizer window, as well as deleting the files in ~/Library/MobileDevice/Provisioning Profiles. Then restart Xcode and reimport the provision profile.
I haven't been able to do this without changing the .xcodeproj file, but that's probably because I've had terrible luck getting things to work without going through the whole "build clean, deselect the provisioning profile, reselect the provisioning profile" process.