Can I avoid my TestFlight overriding my AppStore app - app-store

Can I have the same app in TestFlight and Appstore with different versions without one overriding the other, I mean a users signs up for the Test version, and could he be able to have the AppStore version and the Test version at the same time, each of which should be independent, to avoid errors. Is this possible?

If you use two different Bundle ID's (with appropriate App ID's) for the App store app and the Test Flight app (or Ad Hoc distribution), then your user's iOS devices will treat them as two different apps (e.g. let both be installed, run them both side-by-side on iPads, etc.) But that essentially means you have two different apps, with two different iTC pages and build submissions, etc.
If the Bundle ID's are the same, iOS will only allow one at a time to be installed on a device.

Related

iPhone and iPad project, submitting to apple

I finished working on one iPhone app, and my client wants to port it over to iPad.
Now I created another storyboard for the iPad UI in the same project, and have the iPad UI working and sharing some code with the iPhone code.
The project has one target, with devices supported as universal.
My question is: My client expects that I present him with two apps, one for iPhone and one for iPad, will this configuration work?
When I submit this to the app store, will it know to split it into two apps, or should I just create a separate project for iPad all together?
Thanks.
With your current configuration it will upload to the app store as one app, but for users logging in it will display the correct app depending on the device they use on the app store when they search for it.
So depending on if your clients wants two separate APK files or if they want two apps on the apps store:
If the client is requesting two separate apps you will have to split the project, unless there is an easier way that I am not aware of.
You can also explain to the client that with the current configuration the app will have a little plus icon on the app store to indicate that it is a universal app and will work on both devices, which will be determined by the device they use to download and open the app.
If they want to sell the app, again as far as my current knowledge allows, you will need two separate apps as you can not set different prices for it in the current configuration, this statement is under correction. Unless your client wants to sell both iPad and iPhone apps for the same price then you wont have an issue.
Hope this helps
No, it will not, because it's the same bundle ID, so in this case, in the App Store you'll have one universal application.
If you want to have two applications, you should create a new Xcode project that supports iPad only.
What you can do is to create different target, one for iphone and the other is for ipad. You can follow the answer on this question, it is quite good. Because you have 2 different target, you can have different bundle identifiers, specify different AppDelegate, but all the other code could be shared

Multiple appstore application versions - regular and certified

I have to get a certification for my app for government customers. So there will be two (similar) apps in the app store - regular (development) version and a certified (frozen) version.
My question is - what should be different in the new app?
- new app name (e.g. My Certified App)
- new bundle id (com.mycompany.my-certified-app)
- new push certificate for the server?
- new images?
I have never submitted a lite/full version app before, maybe this type of thing is all too common.
Thanks!
You just need a different bundle ID to make two apps (they'll need to have different names in iTunes too, but the name on the homescreen / in the project can be the same).
You can create a new target for your app, and that will give you a second info.plist. That lets you specify different bundle IDs for the two versions without needing to physically copy and paste the whole project.
However you may have trouble getting this approved by Apple if both apps are identical apart from the version number / certified status.
If one app is just for testing, can't you use TestFlight or something similar to allow your customers to try the app in beta before it's certified?
I would suggest adding "- Certified" to your app name. There are plenty of examples in the iTunes store of full versions, and "- Lite" versions.
In addition to the name, it is customary to have the app icon reflect the different versions.
SeeRoboKill, and RoboKill Lite as one example.

iPhone/iPad Project Upgrade and Universal vs different Device specific projects

According to the topic Using a Single Xcode Project to Build Two Applications, I should choose to 'Upgrade' the iPhone project to include an iPad. However, the page does not discuss pros/cons of Universal versus Two Device Targets.
I think the most desirable benefit of an upgrade is the 'single source' - write once run everywhere (unlike Java and its 'debug everywhere').
I would like to know the problems encountered in the field when using universal binaries versus distinct targets?
The most common reason to avoid building it as a universal app is if you want to charge more for the iPad version. A universal app has a single App Store entry. Building it as two separate apps lets you submit it twice, and set different prices for them.
The single/double App Store entry issue has a lot of ramifications - merged/separate reviews and ratings, release charts, promo codes, etc. They are essentially different apps from the App Store and end-user point of view.
I'm not sure what you are getting at with the "single source" point. Just because you are generating two app bundles, it doesn't mean you've got two copies of the source code.

upgrading separate iPhone and iPad apps to a single universal binary

I have two separate iPhone and iPad apps that I have now turned into a universal binary. I think I've done the hard part, but now I'm kinda stumped on how to submit that universal binary through iTunes connect in a way that users of the existing apps are prompted to upgrade. I know I could just submit this as an entirely new app and then pull the old stand-alone apps down, but I would lose the continuity of reports, reviews, and the prompting of the current users to upgrade....
Any tips?
I don't think you can, both your iPhone and iPad apps as have separate bundle identifiers on iTunes Connect. To be able to make users upgrade, and to keep your reviews and everything - you need to have a single bundle identifier.
What I can think of is - remove one of the apps and update the other one to the universal binary.

Is it possible to install third-party apps on an iPhone? If not, how is it controlled?

Can I go around Apple and offer applications to users, or do they force you to go through them? How? Just legally?
Aside from the App Store (and jailbreaking), Apple provides two official routes to install applications on the iPhone.
Enterprise Distribution: designed for internal users of a company
Ad Hoc Distribution: allows your app to be installed on up to 100 iPhones
Source: http://developer.apple.com/iphone/program/distribute.html
For phones that are not jailbroken, distribution rules are enforced by the iPhone's code-signing system. The phone won't run any apps that aren't signed by Apple, and the only way to get an app signed is either to get it into the app store or to use ad-hoc distribution.
Ad-hoc is effective but time consuming for more than a few devices, in that you have to get the unique device ID for each device you want to distribute the app to. You then sign the app for that device and send a copy along with a provision file. Some batching is possible-- you can get up to 100 devices in the same ad-hoc build. But if/when Apple finds out you're doing it, they'll close your iPhone developer account (for violating the rules) and then you won't be able to generate any more provision files.
One developer tried using the ad-hoc approach last year when Apple rejected their app (Podcaster). They claimed to have sold something like 1100-1200 copies before Apple shut them down.
Jailbroken phones don't have this limitation, but it's up to you to determine (a) whether the market is big enough and (b) whether enough of those people will be willing to pay for your app. I don't know the answers-- it could well be "yes" to both-- but don't just assume they're true without investigating enough to make a reasonable prediction.
If you wish to distribute applications to phones with out going through the App Store, you must sign each copy of your application for a specific phone handset. If you need more wide spread distribution, all your client phones must be "jail broken". Once a phone is jail broken, it will accept any application for installation.
You can offer applications through Cydia for jailbroken iPhones / iPods. Cydia uses a system similar to Debian's apt. Basically allows users to add custom "sources" (repositories) and install applications provided by those sources.
Obviously this is not supported or approved by Apple since it circumvents the App store and their App approval process.