Reputation: 877
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...)
Upvotes: 3
Views: 4815
Reputation: 1954
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.
Upvotes: 2
Reputation: 41005
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.
Upvotes: 1