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.
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!
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.
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.).
Is there a way for an iPhone app to determine which country's app store it was downloaded from? I need to disable a feature if the app is being used in certain countries. NSLocale and MKReverseGeocoder are both options, but both have limitations:
How to get user's country information
Basing the app's behavior on which app store it was downloaded from might be a better fit, if it's possible.
There is no API exposed to do that. You may consider creating separate targets. One with all the features, and another, with the specific features removed. You can then create a separate app ID and sell it within the designated countries that need the alterered version. Creating separate targets and controlling flow with compile time if blocks will allow you to accomplish what you desire while maintaining a single codebase.
See also:
Building for multiple iPhone targets in XCode
I frequently find that I need to have a build on my iPhone which is my 'demo-ready' version which might point to my demo server. I also want a build that is the latest and greatest debug build that I'm developing with that points to my development server. Has anyone found a really simple way for me to install two apps that perhaps are the exact same code but point to different servers? Alternately perhaps I would have an app that was a few versions behind the latest version? Preferably I would use the same XCode project to build and install onto the iPhone.
You can add special build configurations for them that each use a different info.plist file. So, maybe for your demo, you have an info.plist named MyApp-Info-DEMO.plist and MyApp-Info.plist for the release.
Then you could add your server variable as an info.plist variable and look it up when the app starts. Or even just create a DEFINE statement in your new configuration that's something like SERVER=demo.myserver.com for the demo and SERVER=production.myserver.com for the live.
The most important part is to change the CFBundleIdentifier in the new info.plist. So in your demo, you could name it something like com.mycompany.myapp.DEMO and the real one might just be com.mycompany.myapp.
This will allow both versions to appear on the phone at the same time (the different CFBundleIdentifiers). Just remember, if you are using in-app purchases or server push notifications, you won't be able to do this without a separate, specific profile for both your real app identifier and your demo one.
You could create 2 different targets with 2 different info.plists and 2 different preprocessor defines (in the Build Settings for each of the 2 targets). Then ifdef on the preprocessor defines to select the server constant the compiler uses for each target.
Then make the product name and the bundle ID different in the two different target settings (so that neither the device or the Simulator will confuse the two app bundles).
With the current version of Xcode, you'd achieve this by changing the app's Info.plist file to use a different bundle identifier (and possibly also change the Product Name of the app in the build settings).
The upcoming version of Xcode, from what I've read in the prerelease documentation, has a feature that may simplify what you want to do quite a bit. However, since prerelease software is covered under NDA, I can't give you any details.