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!
Related
I have created an iPhone application. I don't have the iPhone and I want to test the application on the iPhone of my friend who is far from me. How can I test it on his iPhone?
When I searched on google, it told me that you need to have the device with you. Is it possible to send the wrap and send the application to a remote location and get tested from there? I also have the Apple ID and license.
Yes with a tool like TestFlight you will be able to check wether or not your will work on a device. Thus is good for acceptance testing but never for technical working of an app.
But when it comes to really testing a device is needed, there is not way around it. You should do performance testing on a device.
Also there is no way to use the debugger unless it is connected to your development machine.
If you are developing for iOS get an iOS device.
It's possible, check Test Flight:
https://testflightapp.com/
I used it in the past for the same scenario as you
You should have a device yourself for testing on, before you publish anything in the App Store. Testing in the simulator is just not the same as testing on a device.
On developer.apple.com you will need to create a Ad Hoc distribution profile. You will also need to add all the devices you want to run the app on to this profile. Once you have the profile and you have it installed in Xcode, you can run an Archive build and sign it with the distribution profile. After this you can select the archive and click on 'Distribute...' to generate a .ipa file.
Once you have this .ipa file, you could use a site like testflightapp.com to distribute the app to test-devices. (you could also just email it ;-) )
If you are looking for just a way to transfer the ipa to someone else the best simplest solution for that would be http://www.diawi.com/ or https://appsendr.com
Get the target Device UDID and add it to your testing list, Create your IPA, drag it to the site above, Done.
No need to signup or anything like that.
I like appsendr better because of the small app they provide.
Lets you drag the IPA to your tool bar and have the ipa url right in your clipboard once it's uploaded.
I need to show my app to customer but without sending sources codes to him.
He does not own any iDevice at the moment, but only a Xcode installed on his host with iPhone simulator.
So my question is there a "normal/official" way I can pass him the application binary so he can test it on his simulator ? Probably using xcode archiving ?
PLEASE NOTE : I know what is ad-hoc distribution, please do not suggest this, he does not own a device.
NO. You cannot give him the ipa to launch it in simulator. Only the source code. (If he is smart enough to launch it, I think you guess how confused will the client be when you try to explain him stuff around the provisioning profiles and certificates and keys to pair them) ....
I see your problem - however, if this is just about a small tour through the app and not a long time testing, might I suggest another way around this:
Why not using a screensharing app like TeamViewer, which has a version that works without installation and is quite hassle free. And then let him play with the App running on your computer?
Sorry for not having an answer on the question, but that would be an alternative route to take.
Very simple solution:
Set up a contract with penalty fee if he copy's the code or distributes the code that'll settle you for life.
If he doens't own a device, you could also loan him one with the app installed. Just do an iphone without a sim card or an ipod
Creating an ipa file and run on the simulator is not possible. We can run the simulator using Xcode only. (means by sharing the code). If you are not interested, ask him to buy device.
I recently recovered from not being able to test on my device in Xcode. After much headache, it turned out that I only needed to uninstall/reinstall iTunes, but I'd certainly rather not do so frequently.
(See: prior thread)
The troubles seemed to begin after I built and ran some sample projects which obviously did not have my App id, etc. Is this always the case? Should I live in fear of compiling other projects that I haven't previously associated with my device and/or developer profile?
I'm not exactly sure if the App id/bundle/provisioning/keychain/whatever needs to be done per test ad hoc App or if it only matters that your device is provisioned and your plist matches what Apple has when you go to upload to the iTunes store.
I've run many samples on my device through Xcode and never had any issues. There's certainly no reason why this should happen.
It's hard to say "No, you shouldn't be worried" without knowing what the issue is, but it's not intended to break in this way, and it doesn't for most of us!
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.
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. :)