So, I basically developed and tested my app using a developer provisioning profile.
now i'm almost ready to submit my app to the app-store, and I was going to use the app-store provisioning profile. so I don't really need to mess with the ad-hoc one at all right?
(I think it's some kind of voodoo magic for multiple developers or something?)
thanks
You only need ad-hoc if you want to test further with others. It is basically the same as the final approval provisioning. You have up to 100 users that can install your app.
Ad-hoc provisioning helps you test at a larger scale than your single developer test.
Testers will always find a way to break your app, so it is a good practice to use this step to help reduce your bug count and smooth your approval process.
Ad-Hoc distribution is outside the App Store. You must sign your app with the Provisioning Profile approved for Distribution and for you app. That is to say if you are specifying an App ID. That latter is common if you are doing Push Notifications or In App Purchases.
As Jason said, you will need to go through the provisioning process in order to submit your app to the App Store. It can be a tedious process the first time - but you can't avoid it.
That said, Distribution builds (non-Debug builds) are different executables. So, it makes sense to test them as such. It is unlikely that problems that were absent in the Debug build will suddenly manifest themselves in the Distribution build - but it's possible.
Also, unless you have at your disposal every iDevice with every combination of iOS releases that you are targeting, then it's nice to have others help make sure that there are no gotchas.
Bottom line: I wouldn't consider submitting an app to the App Store without first deploying Ad Hoc an build on all my devices and sharing it with a few other iDevice users. But, YMMV.
No, it's not necessary. :)
Related
As part of our software development life cycle, we want to make sure that the binary we test in house before pushing to iTunes, is the same as the binary that we push to iTunes. I know that sounds really silly, but it's a matter of checks and balances in a mid size company, so that the testers can be sure the coders didn't add in anything after testing occurred.
So is there a way to run a signed/certed app on a device that's not jail broken? Or is there a way to verify that an IPW is the exact identical code in the zip that gets pushed to iTunes?
Or possibly a way to accomplish my goals with a different way?
We have a valid developer account and around 15 different devices that are not jail broken. Would prefer to test with them left stock and not jail broken.
If you compile your app for distribution using an ad-hoc profile you can later take that archive and resign it with the appstore profile and upload it.
You can't however upload an application that was compiled with an development certificate.
A binary signed to go to the App Store cannot be run on devices via the normal ways. You can test the code by having the developers create an Ad Hoc build. This will have the same functionality as the App Store version, but you can test it.
Unfortunately, when the app is recompiled for the App Store, more code can be added.
Do you not have access to the code to test? If you must, you can have them create an adhoc in front of you, test it, and then recompile for the app store all in front of you. Seems a bit overkill, however.
There is with another trick:
first test you code for functionality's, buggs in normal way.
Than push the code to AppStore, but set the release date farther with 3 weeks, while your testers are validating it is that what they tested last time or not. Somewhere here, I have read that possibility forgot where. Never tried!
There are split opinions and contradictory information about TestFlight.
Some sources say you need to go through the old AdHoc Distribution Process and TestFlight only collects UDIDs for you and then helps you spread your AdHoc Build. The same thing you could do with Email.
Other sources say:
Testflight allows you to simplify this process immensely. You just
build a normal debug IPA and then put it on TestFlight. They have
their own global provisioning profile the users install and run the
app with. It's as seamless as mass testing on iPhone can be (Granted,
that's not a high bar).
What's the truth? Do I need to mess with AdHoc and UDIDs myself, or is this part done by TestFlight? Do I need to make a normal Debug Build just as if I was building to test on my device, like the quote claims above?
According to this tutorial I do have to mess with the UDIDs myself. No mention of any fancy global Enterprise Profile of TestFlight. Limited to 100 devices.
How does it really work? And what's with that Enterprise signing myth? Can someone debunk that?
You have to mess with UDIDs.
In fact, TestFlight just reads the provisionning profile attached to the ipa you sent. Authorized devices are knwon thanks to that provisionning profile.
I usually use AdHoc profiles, but it should also work with development profiles.
All that matters are that the UDIDs are on the profile that is used in the Archived build. Is it Developer or Distribution? It doesn't care. It does make it easier for you to be able to filter out who gets what build (i.e. only developers can get debugging builds whereas your larger team gets release builds).
I'm making an iOS app for a client, and need to share my progress with them in a convenient way.
At the moment I know of two options:
add their device to my provisioning profile then send an IPA to them
send an app through to them, built for the simulator, and have them run that directly
Neither of these are ideal, as the simulator doesn't give the full experience, and getting UDIDs off non-technical people can be painful.
Are there any other options I should know about?
I use testflight - iOS beta testing on the fly. I used to battle with the same problems you mentioned but once I started using testflight, I didn't look back. What testflight allows is -
You can add the specific customer to send the IPA to.
Progress reports
No need for your customer to go through the complicated Provisioning certificate
No need to register your device
You can even create groups and send different builds to different groups. Like "Test Group" would get more bleeding edge builds whereas the customers might get a more stable build.
Free over-the-air beta distribution. Apps are installed in one tap over-the-air and users will be notified of future builds.
Recruitment: Promote your beta app and select new users that sign up
Works within Apple’s guidelines and rules for ad hoc provisioning and device # limitations
You don’t need to jailbreak or alter your phone.
It is not a replacement for Apple’s ad hoc provisioning profile and device limitations.
Hope this helps...
PS: I do not work at testflight & this is not a promo. Just appreciating a good product...
UPDATE: Recently test flight has launched TestFlight Live, pretty awesome for tracking launched apps. This is all with detailed flowcharts et al. Definitely worth a dekko. Defunct after Apple buying TestFlight (or available in different name)
LATER UPDATE: Apple has bought TestFlight. Links updated.
https://testflightapp.com takes a lot of the pain out of circulating iOS app builds. It's free and it's worked very well for me.
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.
The background story:
I work for a company that develops and manufactures a commercial product which can have up to 100+ dedicated PC's in a farm.
We only get a handful of new customers per year.
We developed an iPod/iPhone app that lets us send commands to the farm and pull data. Our parent company has major concerns about putting this app on the AppStore. (I really dont know the details of the paranoia, but I know its probably not a winnable battle).
We planned to distribute the App via Ad Hoc using ONE or TWO new iPods each time we sell a "farm". I have just learned that the Ad Hoc distribution expires after 90 days.
The Question:
Are there any alternatives for permanently loading our app onto an iPod Touch or iPhone without going through the App Store?
Our app has absolutely no use to anyone without our other product. We only plan to load this app on a handful of iPods a year. I doubt this matters, but maybe somebody has another solution?
Apple has an an enterprise distribution program, which might allow what you're trying to do. There's also jailbreaking the iPods. That would let you run unsigned code, so you could build your apps without ad-hoc certs.
I know this post has been marked as answered but i am in the same situation so i though i should share what i have experienced.
There is NO legal solution for this. You can't have an app distributed with out the annoying expiry dates.
I have been onto the ADC support and you can't get an extension on the certificates, you can renew for more than 1 year at a time and they have no interest in helping you.
I have clients who will not let the content of their apps hit the app store. There for they are stuck with sending all the devices back to renew certificates (i know you don't need to xcode etc.. to install the certs but try getting end users to do it...).
I am in the luck situation that i can try send the shell of an app to the appstore and then once verified (i.e. once off login - ssl to our server with the device id and a guid password) the app will download all the sensitive content to the phone.
I don't know if this will work for all apps - i.e. loading classes or libraries dynamically but for me it is only the content that is sensitive.
if anyone would like more info i am happy to talk it over, but i haven't tried getting the app through the store yet. I will try soon, so i can keep you posted if you are interested.
cheers
kle
As of September 2010, Apple has removed the 500-employee requirement. Go nuts!
See my post about setting up an Enterprise Program account (which moderators keep trying to close!):
https://stackoverflow.com/questions/1876333/how-long-does-it-take-to-get-an-iphone-app-into-the-app-store-closed
Issues with getting an Enterprise Program account:
-You need 500 employees.
-You can only provide the app to employees.
Make sure you check the detailed terms and conditions of using Ad Hoc distributions to be sure you are allowed to distribute them as you are doing. On the face of it you are probably okay (Apple link here), but worth checking the fine print. I know the Enterprise Program had a lot of fussy fine print, e.g. needing procedures to recover apps from employees when they leave the company, etc.
If you jailbreak the iTouch/iPhone then you can easily disable Apple's code signing checks. You can then build your app and load it onto the device as normal without worrying about expiry or anything else.
The only problem is that jailbreaking on newer batches of the 3GS is not particularly end-user friendly. For something to give to a client I think you would need to stick with the iTouch.