Building for the World, Not Just for Turkey

The cost of building an app has nothing to do with how many people will use it. You write the same code, you run the same tests, you go through the same store process. The only difference is how many people it reaches.

That is why I try to design my apps with a global audience in mind from day one. But I learned this early: saying "I translated it into English" is not the same as being global. There is far more to change than the wording.

Text expands, the interface breaks

A button label you wrote in Turkish can grow by roughly a third in German. "Kaydet" ("Save") fits in a fixed-width button and still fits as "Speichern", but "Ayarları kaydet" ("Save settings") overflows once it becomes "Einstellungen speichern".

• Do not give buttons and labels a fixed width; let them grow with their content.
• Wherever you assumed a single line, test two lines as well.
• Review the interface once in the longest language — German is usually a good stress test.

Dates, times, numbers and currency

Formatting these by hand is one of the most expensive mistakes you can make in a global app. dd.mm.yyyy is right in Turkey and wrong in the United States. The decimal separator is a comma in some countries and a period in others.

The fix is simple: use the platform's own formatters. DateFormatter and NumberFormatter on iOS, and DateTimeFormatter and NumberFormat on Android, already produce the correct output for the device's region.

Price is not a currency conversion

When you set an in-app purchase price, the easiest path is to convert the Turkish lira price to dollars and leave it there. It is also the most wrong one. Purchasing power varies enormously between countries; the same dollar amount is cheap in one and out of reach in another.

Both stores let you set regional prices. On top of that, every country has its own "psychological" price habits — 4.99 looks natural in one country while a round number is expected in another. Using the regional price tiers the stores suggest gives a better result than doing the math by hand in most cases.

Localize the store listing too

Translating the app but leaving the store page in English is the gap I see most often. Yet the store page is the first thing a user sees. Someone who does not find a description in their own language will not even download it.

• The title and subtitle should be written separately for each language — not a literal translation, but the words people actually search for in that language.
• The text inside screenshots needs translating as well. If the captions on the images stay in English, the translation looks half-finished.
• Do keyword research separately for every market; a term that is popular in one country may not be used at all in another.

Cultural details

It helps to remember that colors, icons and examples do not mean the same thing everywhere. A thumbs-up, hand gestures and certain color choices can read differently from country to country. Sample data has the same problem: if the example names, addresses and currencies inside the app are all taken from Turkey, the product feels "local".

Schedule notifications in the user's own time

A notification sent according to server time reaches a user on the other side of the world at three in the morning. The result: notification permission gets turned off, or the app gets deleted outright. Schedule notifications by the user's local time.

Which languages should you start with?

You do not have to do all of them at once. My approach is this: launch in Turkish and English first, then look at the country-level download data in Play Console and App Store Connect and add the languages of the markets that are already showing interest. Expanding on data rather than on guesses costs less effort.

Thinking globally means a bit more work up front. But localizing after the fact is always more expensive than localizing from the start.

• Localization
• Global market
• i18n
• Pricing
• ASO