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.
Related
I have an app that has been released on the app store with separate versions for iPhone and iPad. Now I wish to convert the app to a Universal version but I have an issue which I'm not sure can be resolved.
Both versions of the app use a different bundle identifier (for example com.mycompany.app.iphone and com.mycompany.app.ipad). I want the new (universal) version to overwrite either of the old versions when downloaded from the app store. To complicate matters further, core data stored for that app needs to be retained.
I'm not sure its possible and perhaps the protocol is to release the universal version under a new bundle identifier and have users start again but if a workaround is available it would be really helpful.
your options:
1: Update both your iPhone and iPad apps with this universal binary (with respective bundleIDs and app names)
2: Create a way to sync data between apps by creating a web service. one of the apps I have used extensively - Gas Cubby, does this for transferring data from its free app to paid app. You could implement it in a similar way
3: Nuke one of the apps, update the other app with the universal binary
Option 1 is the easiest. 2 will take longer. 3 is dirty.
(will update this answer with more options if I come across any)
As far as I know and from what I've read before, you can't change the bundle identifier of an app published in the app store.
Due to the sandboxing, accessing the data of your old app from the new app is also impossible.
There are several ways you could go about solving this issue, depending on which one suits you best. You could create a new universal app, and abandon the old ones hoping that the users change their preferences, or you could be pushing the same update to both applications, essentially, having the identical app under two different names. I'm not sure what are Apple's stances on the second option, but it will be a hassle either way. Good luck!
Hi guys I need some help with Apple App Store.
I've an application that is localized in several languages and I want to release a different bundle for each language (to reduce the app size).
Can I use the same app name?
Thx,
SL3
You can't use the same app name or have multiple binaries for the same app version. And as Radek said, it would be a bad idea anyway.
Localizing an app in various languages should not require that much more size to make you think about splitting it in different bundles.
By the way, it's a bad idea thinking of publishing different applications for different localizations, for a couple of reasons:
You will have to handle n different development/release/review streams, with great problems when you need to update the app (Apple will have to review n versions instead of one)
A user will not be able to switch languages if he likes to. Think about a Spanish person that lives in Italy. Which version should he download?
If you use dedicate developer profiles under Xcode, you should create and import a different one (or a different group of them) for each localized version.
Also, you will split all the number of downloads, reviews and so on between the apps. If your app is downloaded by 10.000 people its great! But if you split it in 10 pieces, you will have only 1.000 downloads each (mean value). This will greatly affect the scoring in the App Store ... and that's not what you want!
If you built the app in a clean way, adding a localization should result in adding a simple text file, and that is not so heavy.
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 noticed that there are different requirements for each platform here. I was wondering if it's possible to build a single project but with multiple targets where each target is Mac OS X (something like a CD / install build), Apple Mac Store, and iOS device.
IfIi'm going about this the wrong way then I'd love to know! I mostly develop on the PC but with the state of the App Store I'd love to spread out as much as I can!
Keeping separate targets for the Mac app store and an independently-distributed Mac application is simple. You just need to ensure that your receipt validation code is conditionally included on the app store target and not in the other target; and your custom licensing scheme is included the other way round. Things get a bit more complicated if you target different operating systems in the two targets, but they're not insurmountable: you can test for the existence of classes or selectors at runtime to ensure you never call newer API on older systems.
By the way, it's also worth having separate Info.plist files for these targets. Partly because you don't need or want to include things like Sparkle properties in your app store target, but also because each target should have a unique bundle identifier. The app store does odd things when you have an app installed that it thinks came from the store but really didn't, and you don't want to risk your updater or Apple's trying to update the app deployed via the other mechanism. But that's not really about organising your Xcode project, it's a deployment issue.
For the most part, yes. All Mac/iOS apps can be written in Objective-C and the code is very similar. However, you must bear in mind that iOS devices have different screen sizes from the Mac and even from each other. That means that the input metaphor is different, and that the UI is different. While it is possible to do what you want, it's not advisable to just code once and compile thrice.
That said, I don't use Xcode 4 so I can't tell you about that. Of you are looking to do different builds for different devices, you will want to write your app logic and your input logic as separately as possible. Then, you create multiple targets, one for each build. You define compiler flags for each target. In your code you will use those flags to use the appropriate code for your build.
At least as of 3.2.5, this is absolutely not a problem. You won't necessarily be able to apply all of your build settings project-wide, but you can specify them on a per-target basis.
Just add the appropriate-type target (Cocoa Touch, Cocoa, etc.).
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.