I have an app on the Swedish App Store which I intend to adapt to some other markets. In this case, the most important part of the localization is to change some aspects of how the app works for different markets (countries), so this is not primarily about language adaptations.
Probably, I will not use the normal built-in mechanisms for localization. Instead I consider to build separate versions for different markets and release them as separate apps on App Store (with the same icon and similar names), with each one of them only available in one country.
My main arguments are,:
1) Since App Store supports fewer languages than iOS, there are several countries where Apple has defined the App Store language to be UK English (e.g. Denmark, Norway). Then I cannot create a good sales pitch in their own language, unless I release completely separate apps for these countries.
2) I think it will be faster for me to implement the localization, in this particular case, by inserting compiler directives in the source code and make different Xcode targets for different markets. (This may be caused by a not so smart architecture of the first version of my app, by nevertheless, this is the current state.)
NOW, MY QUESTION:
Are there any drawbacks of releasing separate apps for different markets, except the obvious one that there will be more administration? (e.g. less favourable for achieving good ranking on App Store, risk of rejection, etc...)
It is not possible to publish 2 apps with same name in the app store
Risk of Ban
App Store supports fewer languages than iOS Localization
iOS Localization is faster than creating multiple copies
Maintaining multiple copies, changes and updating all of them is a huge overhead
Less favourable for achieving good ranking on App Store
Risk of rejection
App Store Review Guidelines, one of them is that
developers should not "spam" the app store with multiple versions of
the same app with minor changes.
Apple are not a big fan of this approach generally. I heard somewhere that there was an unofficial limit of three copies of the same app for localisation reasons, but I don't know how concrete that is.
Would it not be possible to build this logic into the app? You can use the NSLocale to get the device locale (not just language, also country) at runtime, and then use runtime logic to switch out view controllers, nib files etc. If your app is not well structured, you could just branch at the MainWindow.nib level if necessary, and then have complete control to change any aspect of the app when it loads.
I think this is a better approach than releasing multiple app versions for the reasons you mention, as well as avoiding hassles getting your app approved. It doesn't solve the app store notes problem, but perhaps you can work around that another way, by focussing your marketing strategy on a web site or something external to the app store.
Related
For marketing (as opposed to technical) reasons I'm about to submit a financial services iPad app that comes in two flavors, "regular" for individual users working on their own behalf, and "professional" for financial planners working on behalf of clients.
The "Pro" version functionality includes everything in the regular version and also provides the ability to save and switch between client datasets. Most of the code is identical, only a tiny sliver of code is added to the Pro version build (although more features may be added in the future that might widen the gap in functionality).
Here's the question: Is it better to maintain two separate apps in the store (with separate application IDs?), or as a single app with an InApp purchase to upgrade?
I'd rather avoid the infrastructure of InApp purchase, but I want to "color between the lines" of Apple policy and keep it reasonable for users and for future development.
Most "regular" users will never upgrade. But many (most?) "Pro" users will probably want to start out with the cheaper single user configuration before spending significantly more dollars on the "Pro" version. Advice on how to package?
It seems like the best bet is to create a second target, setup the project to archive both, and then load them as separate apps to the App store.
I base this mostly on reading between the lines in the various answers about provisioning (at least there seems to be some evidence others have taken this route). I'd still welcome comments or other input from those who have gone down this road (or taken the other one). Thanks.
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.
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.
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
There has been a lot of talk around iPad-Apps / Approval / Store-related Questions. I've recently built an App which I'm just about to release / send to Apple for approval.
I'm thinking about developing a dedicated iPad-App as well.
Now, in order to not have two seperate Apps in the Store (one for the iPhone, one for the iPad) i want to create an universal-App for both platforms.
However, i couldn't figure out if it is possible to first send in my iPhone-only app and later publish an update that enables my app to run on both platforms.
Does anyone have an idea on that topic?
thanks in advance
sam
Yes, you can update an iPhone app to become a universal app.
Many apps are already doing that. Universal apps provide the better user experience, I think, as they reduce the number of "duplicates" in your iTunes library (and on your iPad).
Unfortunately, a great many developers are going the "two separate apps and make the iPad one really expensive" route instead, too.
The only downside to universal apps I can see is the increased size (all the iPad-only stuff that iPhone users do not need), which could be a factor for the more fancy applications. Does anyone know if iTunes is clever enough to strip this out when syncing?