I've got two branches of an iPhone app going. I would like to load them both onto my provisioned iPad at the same time. The iPad sees them as the same app though and writes over whichever one is currently installed. Does anyone have good system for loading two versions concurrently. Thanks!
The bundle identifier is what is used to identify different applications, so if you were to temporarily change it for one of them, that build would show up as a different application than the other. It would still have the same icon, name, etc., but the system would think it was a separate application.
Related
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
I currently have an Universal iOS app, but with the new iPad3 device we needed to add resources/sprites for that specific device, the problem is that the size of the IPA has become incredible larger thanks to the huge new screen. I was wondering if its possible to have only one Xcode 4 Project that could generate two different IPAs, one with target:iphone and other with target:ipad, that could also include or exclude files depending on the file extension, for example blah-ipad.png wont be on the iphone version.
Thanks!
#Conrad Shultz is correct about why you shouldn't split an existing paid app into two.
For people who haven't released their app, or whose app is free, it's worth knowing that you can duplicate a Target by right-clicking (or control-clicking) on it and selecting Duplicate. I'm pretty sure Duplication is only offered through this context menu. The more obvious 'Add Target' options involve creating a whole new Target and manually duplicating the contents and settings of your existing Target.
Once you have multiple targets, you can specify which resources are distributed with each.
Edit: you will also need to change the 'Devices' setting if you have an iPhone Target and an iPad Target.
If you have a lot of resources, consider including them in folders with Folder References. Then you can specify target membership for the entire folder, without having to change individual files. This will change the path to those resources within your bundle, so plan accordingly.
Yes and no.
You can certainly set up different build targets (and schemes) for different products, targeting different device families, different architectures, even entirely different platforms (OS X vs. iOS). You can of course include different assets in each. I personally do this all the time, so if that's what you're looking to do, let me know and I'll try to provide further details.
But what you can't do is submit multiple IPAs for a single product to the App Store. If you are already distributing a Universal app through the App Store, your only recourse would be to pull it and create two new apps with new bundle identifiers, product names, etc. (I don't think, but I could be wrong on this point, that you can even downgrade a Universal app to a single-family app, but that's something you'd have to check in the developer/App Store documentation and agreements.)
If you went this route, you would force existing users to purchase the new app again at full price. This would likely be poorly received by customers. If I were you, I'd look at whether the size difference is really large enough to worry about and, if so, look at strategies for reusing assets across devices (for example, downscaling higher resolution images on #1x devices), though this introduces possible performance penalties.
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.
I have 2 iPhone apps and want to deploy to iphone and somehow the second app rewrote the first app on my iPhone.
The second app project was copied from the first app and I made some changes including renaming the app name etc.
I believe there might be some files messed up due to the shared path. Can anyone shed some light on this issue?
You need to make sure that the two application's bundle identifiers are different, otherwise they will be treated as different versions of the same app.
Look for the CFBundleIdentifier (Bundle Identifier) key in your application's Info plist. Make sure this is different for each application.
I have two versions of my app. I'm trying to keep a copy of each on my iPhone for testing purposes.
In my build settings, my bundle display name is ${PRODUCT_NAME} and I've given each version of my app a different product name (eg "v92" and "v10"). When I install each version to my iPhone, they both appear side by side with different names, however one will work normally, and the other will immediately close the moment it's opened. If I delete the version that works normally, the other will start working.
Does anyone know what's going on?
I think the apps are distinguished on the device by the App Id and not the product name. I dont know how you were able to install two apps only by changing the product name. When i mistakenly installed a different app with same app id but different product name the original app was overwritten.
Try creating a separate app id for the new version only for testing. That might solve your problem but make sure you use the correct app id when you submit your app.
EDIT: It might not be the right solution if you are doing some app id specific stuff (like APNS) in you app.
I ran into this one too and eventually solved it. I know the solution had to do with changing something in the information property list, but I'm not sure exactly what. I would suggest making sure that all of the following are different for your two versions:
bundle display name
executable file
bundle identifier
bundle name
At least you can create two app id's and two provisioning profiles in your developers account. Then you'll be able to install your 2 versions like a two different apps. It's an ugly solution, but it definitely works.