CODEWITHSUNDEEP
iosinternationalizationapp-storeapp-store-connectcommon-code
CoolDocMan
CoolDocMan

Reputation: 638

International iOS App - common code base with different versions

We have an iOS App which has millions of users in the US and needs to be Internationalized and made available in 11 different countries (many with a different language). Have worked out all technical details for exposing hiding features as applicable to a particular country, and also the different currencies etc. We have also implemented a way for the app to get location (if it is switched on, otherwise request user for it) and based on that, to self-configure for the country/language.

We'd like to do this off one Code Base. Suppose this is currently at version 1 say. Suppose we start with adding 5 countries - i.e. US, plus Korea, Japan, France, Canada and Mexico. Say this is now version 2.

We will then deploy this (a single app with one bundle id) to the App store and set availability for this version (2) to USA, Korea, Japan, France, Canada and Mexico app stores.

Suppose in the next month we add a new feature and that becomes Version 3. We test this thoroughly for USA, but our QA team does not have time to test this for the other 5 countries. So we want to release this V3 only for the USA and set availability for the new version for just the USA.

From what I understand, with the way app store settings work, since we have the same bundle id, we cannot restrict the new V3 to the US alone. It will automatically get published to the app stores in Korea, Japan, France, Canada and Mexico as well.

Is there a way around this?

(the other approach I know is to use the same code base, but build separate targets with separate bundle ids for each country, and I would rather have everything based of one target)

Upvotes: 0

Views: 453

Answers (1)

7vikram7
7vikram7

Reputation: 2824

iTunes does not support enabling new version availability only for a particular region and while letting the old version be available in the rest of the regions. And they do this for a good reason too.

Suppose you support English and Japanese. What you are saying is, as you were able to test only the English localisations of the new version, you decide to launch it in all regions but Japan.

But what if a user who works in the US with English as the device language goes back home to Japan for a few days on a holiday. His son who uses this guy's phone to play some game changes the device language to Japanese. Now when your App is executed, will the end user be exposed to an untested version of your App? Even if you don't localise according to the settings of the OS and have a separate option in the settings panel of your App, the user can always switch to a possibly untested version resulting in bad user experience.

So the only options which I think you have are either:- 1. Testing you App for all languages before release. 2. If the features in the App vary vastly according to the regions, group similar regions and create 3-4 different Apps (XYZApp-US, XYZApp-Europe etc). This option would make sense only if your features vary largely across different regions (lots features need to be hidden/modified according to language). This approach would not only help in timing your releases according to QA coverage but also help in segregating code as only relevant App would have the relevant feature code.

Option 1 though looks the easier one.

Upvotes: 1

Related Questions