I believe I understand out to produce an .ipa file for Ad Hoc distribution to my beta testers, but my question is what settings do I need to allow the beta copy to co-exist with a purchased copy of my App on the same device? That way they can test out the app for me, and fall back to the production app for day to day use.
Thanks,
Rob
Change the bundle identifier. For your app is com.domainname.appname, for your beta could be com.domainname.appname-beta
I would make a new app name and bundle identifier and then name the app (the text under the icon) a different name then send it out. It's a little extra work but it makes it so you won't mess up any existing saved data on your production app.
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!
Okay so here is my situation. About a year ago I released my very first iPhone app! (Yeah). Since then I have been working on making it into a universal app. In doing this, I actually went ahead and created a brand new universal app and then proceeded to code accordingly.
So now I want to release this app but since the app was created brand new, it has a different bundle Id. I don't want to alienate the users that bought the previous version for just the iPhone so is it as simple as just changing the universal app bundle Id to the one I used for the iPhone and publish that way? Will this fly with apples publishing system?
Thanks in advance for any and all help.
Geo...
Should be absolutely fine. The devices will just replace the app with the new version - as long as your new one uses the same data storage / preferences etc there's no reason why that won't work.
NB This answer assumes that you are going to release it as an upgrade to your previous app.
I have an initial build of my app which I want to circulate for testing to few others who do not have XCode with them. All I want to do is pass them the binary which they will install to their devices using iTunes. I have created my developer certificate, created an app id and added the device udids in my provisioning portal.
So now can I directly email them the binary and ask them to drag and drop into itunes and then on the device ?
Thanks!
I tested it myself and it's amazing: You should try Testflight.
It's a simple to use service (free) that allows you to distribute your adHoc builds easy and fast (might sound like advertising but it's really one of the best tools I came across).
Build archive and it will appear in organizer. There is big Share button that allows you to save ipa file which you pass on to testers.
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
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.