I have several iOS/iPhone apps that have been continually selling in small amounts in over 2 dozen different countries, even though the app UIs and all the store descriptions are only in English.  In a few countries where English is not the official or native language, a few apps are selling far better than is proportionate for those country's population size compared with the U.S.

So why Internationalize apps?

What kind of increase, if any, in sales might a typical app see if it is Internationalized into given local languages?  Which major languages might be likely to see the greatest improvement in app sales or downloads due to a localized app description?

Imagine you have a program which has been released. A customer comes along and offers to pay you for a enhancement to one of its features. In order to get the money, you will need to change your program to add the new feature. Some of the things that will influence what your profit margin is are:


how much code you have to change
how easy it is to make the changes
how likely you are to break existing features that are being used by other customers
how much you can reuse you existing model/architecture


Separation of concerns helps you to get more positive answers to these questions.


if all of the code for a particular behaviour of the application is separated out, then you will only have to change code directly associated with your new feature. Which should be less code to change.
if the behaviours you are interested in are neatly separated from the rest of the application it is more likely you will be able to swap in a new implementation without having to fully understand or manipulate the rest of the program. It should also be easier to find out which code you need to change. 
Code that you do not have to change is less likely to break than code that you do change. So splitting up the concerns helps you to avoid breakage in unrelated features by preventing you from having to change code that they could call. If your features are mixed up together you might change the behavior of one by accident while trying to change another one.
If your architecture is agnostic to technical or business logic detail then changes to implementation are less likely to require new architectural features. For example, if your main domain logic is database agnostic then supporting a new database should be as easy as swapping in a new implementation of the persistence layer. 

