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.
Related
I get this error when trying to validate, now theres tons of these questions, the problem is, none of their solutions have worked.
The top highlighted one is my distribution provisioning file thats associated with the project in question.
you can even see it's online.
so I have the profile, I have the app ready for uploading (how do you change the date for when it can be available on the app store AFTER you have said "yes these details are right, now lets get ready to upload?").
But I can't validate. every time I log in to "validate" I get that error. I have all the profiles required I have tripple checked every thing, but being VERY NEW to IOS dev, I am sure I missed some crucial step.
Please help.
1) Have you created a Distribution Certificate and downloaded it?
2) Have you created App Store provisioning profile?
3) Are the code signing identities have been properly setup in your project?
If yes to the above then try manually downloading the provisioning profile from the developer portal and restarting XCode.
I send a new version of my iPad app to AppStore. The Apple will now validate it.
But, I want to have absolute certainty that NOTHING gone wrong. I have the Archived file and want to run it.
Ok, I can build a new program and run it in the device. But I want to test the exact file that I sent.
I tried to create a .ipa file but it give-me problem with "code signed". Run the file in simulator is a good idea. So, there are a easy way to run my new version?
You cannot install on our own device an app you build and is signed with your distribution certificate. Put another way, the build you submit to Apple cannot be directly installed by you on your device.
If you build any other way such that you can install that build on your device, it's the same code as you would otherwise be sending to Apple in a distribution build.
I have had the same desire, actually. I have an app with a conditional build setting based on whether it's a distribution build or not. For a distribution build, we have a production API URL, but for all other builds the URL is a development sandbox URL. So, I know how you feel! I wanted to be able to test the actual build sent to Apple to make sure it was hitting the correct production URL. I couldn't. I had to trust. :-)
I'll assume you're using Xcode 4; details will be different if you're using Xcode 3.
Once you've created an application archive, you can select the archive in the Organizer and click the Share... button to e-mail it to yourself and/or your testers. Xcode will let you sign it with your developer key, so you can install it on your device. When you're satisfied with the app, you can then validate and submit the app to the app store, again from the Organizer window. You'll re-sign the app with your distribution key and the application will be uploaded to iTunesConnect.
Just make sure your project and your target Build settings are absolutely 100% identical between your final Release build and your Distribution build, except for code-signing. Then do a clean build of both, one after the other, and QA the final Release build before submitting the Distribution archive.
After Apple approves the app, delete the app from one of your devices, and buy your app from the App store. That's the only way to get an exact customer download with the full customer experience. You'll get back 70% of the purchase price in a couple months; the other 30% is likely a very small part of your total development and testing cost.
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 was just making a free version of one of my apps. I copied the folder, renamed the project, and changed the icon file, loading screen, interface, and code. BUT YET it still replaces a build on my phone.
1)how do I stop this from happening (i want both the free and paid version on my phone)
2) if you can fix this, will a customer who has the paid, and downloads the free, will that replace it on their phone?
I really need to know these, as I have the app ready to go, and would like to get it before the end of the week.
cheers
Sam
You need to have a different app bundle identifier. I think that's your problem.
Long answer:
Go into your projectname-info.plist file and change the CFBundleIdentifier.
I'd recommend something like:
com.mycompany.mycoolapp for the app store
com.mycompany.mycoolapp-beta for the beta version
You should actually be able to set up the "Debug" build configuration to use a different info.plist file configured with a different CFBundleIdentifier and a different icon filename. That way you'll automaticlly get the beta ID and icon, etc for the Debug build and the real id/icon for the full one.
This should allow users to install and use both the production and test versions of the apps at the same time without confusion.
You might also find this IPA target template helpful if you're doing ad-hoc distribution to Windows users for testing:
http://devblog.appmagination.com/2010/01/target-template-for-building-iphone-ipa.html
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.