The Differences Between Android and iOS App Localisation

When the Turkish version of an app is being prepared, most people picture a single text file. In reality the same app has two platform versions, and those versions do not store text in the same way. Android and iOS app localisation are two processes that are similar in translation terms and markedly different in technical terms.

Contents

Jiménez-Crespo notes that most commercial apps are offered in both an Android and an iOS version, and that when translation memory is used the same memory can be shared to speed the process up (2024, p. 229). The divergence, then, is not in the text but in the container that holds it and in the way it is delivered.

Below we compare the file structures, the tools and the delivery routes of the two platforms, and show which decisions need to be taken at the start of a project.

Two ecosystems, two development environments

The book states that apps are generally produced in a development environment designed for internationalisation, and that tools such as Android Studio and Xcode on the iOS side include functions that make it easier to separate localisable items from the code (Jiménez-Crespo 2024, p. 228).

That similarity is superficial. Both environments separate the text, but they store it in different formats. On the Android side, strings are gathered in XML files. On the Apple side, Xcode separates the text strings into XLIFF files for localisation (Jiménez-Crespo 2024, p. 229).

That difference is not in itself a serious problem; translation tools read both formats. The trouble begins when the two versions are managed at different times and by different teams. If the same button is translated differently on the two platforms, users notice.

Some projects reduce this risk through cross-platform development. The book states that both the Android and the iOS versions can be compiled from a single core app developed in one environment (2024, p. 228). In that case the text also comes from a single source.

A single source does not solve everything. The platforms have different interface conventions, and the same sentence can appear in a different context on the two systems. So even where shared text is used, the results still have to be reviewed separately on each platform.

The Android side: the folder name sets the target language

Android logic is simple and rests on the folder name. The strings in the source language sit in the strings.xml file in the res/values folder. For each target language, a file with the same name is placed in a new folder named with the language code (Jiménez-Crespo 2024, p. 232).

In the book’s example, the English file sits at res/values-en and the French file at res/values-fr. For Turkish the equivalent is res/values-tr. The system looks at the language setting of the device and picks the right folder; the code does not change.

The practical consequence of this structure is that adding a new language amounts to opening a new folder. As long as the files carry the same string names, the app works. If a string is missing, the system falls back to the equivalent in the source language, so the app does not crash but does look mixed-language.

This silent fallback is a feature that makes quality control harder. Because the app runs without error, the missing translation goes unnoticed. That is why a pre-delivery check has to look at whether the string counts match across the source and target folders.

The book also describes how an app can be decompiled, and how in the unpacked file structure the strings.xml file is found in the values folder inside the res folder (Jiménez-Crespo 2024, p. 232). This route is used on projects with no access to the source files.

The iOS side: the localisation catalogue

On the Apple side the process runs through a catalogue. The book describes how, once the target languages have been selected, Xcode creates a localisation catalogue folder with the .xcloc extension, and how the localisable resources for each language sit in that folder as XLIFF files (Jiménez-Crespo 2024, p. 236).

The flow is built on export and import. The project exports the strings in the development language as XLIFF, the files are translated, and they are taken back into the project. The app is then compiled. For the translation side, this cycle provides an orderly and traceable structure.

The catalogue folder holds more than text. The book states that it may also contain a JSON file carrying metadata about the catalogue and a notes folder that can hold screenshots or video for translators (2024, p. 236). These notes reduce the context problem directly.

The advantage of the catalogue approach is that each language stands in its own folder as a complete package. If one language is delivered late, the others are unaffected. The disadvantage is that the source text can change in the time between export and import, so that the two versions drift apart.

Android and iOS app localisation: a comparative summary

Seeing the main differences between the two platforms in a single table makes the job easier when you are drawing up a project plan. The summary below is compiled from the relevant sections of the book.

Topic	Android	Apple iOS
Development environment	Android Studio	Xcode
Text file format	XML (strings.xml)	XLIFF
Language separation	values-XX folder	.xcloc catalogue
Image folder	res/drawable-XX	Resources inside the catalogue
Interface files	res/layout, res/menu	.xib and .storyboard
App package	.APK	.APP

The table shows the same work packaged in two different ways. Stating which column you are in when you prepare a translation request reduces surprises after delivery. On setting the scope, the articles in our knowledge centre may help.

Images and interface files

Text files are the visible part of the iceberg. On the Android side, the images to be localised sit in the res/drawable folder and are copied into counterparts named with the language code. The book gives the example of the default logo sitting in the res/drawable folder and the Italian version in the res/drawable-it folder (2024, p. 234).

The same section notes that folders such as res/layout, res/menu and res/values/colors.xml are also of interest from a localisation point of view. Layout and colour decisions, in other words, can change by language. That is a design decision beyond translation.

On the Apple side, the equivalent is the interface files. The book writes that when Xcode is used, the text to be localised is also found in interface files with the .xib and .storyboard extensions, and that these cover the launch screen of the app (2024, p. 237). If the launch screen is forgotten, the first frame the user sees stays in a foreign language.

The same string, two different variable notations

The finest detail in the platform difference is variable notation. The book describes how the same greeting string is written one way on the Android side and another way on the iOS side, and how some cloud platforms present that difference to the translator in a single shared notation (Jiménez-Crespo 2024, p. 229).

On export, each file gets its own correct notation back. The translator works with a single format and the system takes on the conversion. Without this mechanism, two versions of the same sentence are translated separately and the chance of error doubles.

The same platforms also have repetition functions that ensure similar strings are shown only once (2024, p. 229). On text shared between the two platforms this function saves considerable time, because the overlap is usually high.

Where there is no such mechanism, a check step should at least be added. Once the translation is complete, the files from the two platforms are placed side by side and the variable counts compared. A missing or extra variable can show up as a runtime error in the app.

The delivery route: the files, or the app itself?

The book defines two delivery routes. In the first, the client sends the exported files directly or through a cloud platform. In the second, the whole app is delivered as an APK or APP file (Jiménez-Crespo 2024, p. 228).

The second route demands more technical capability. The app has to be opened, its resource folders located, and after translation it has to be recompiled and signed. The book states that once linguistic quality control is complete the APK file can be compiled and signed, and that functional testing then begins (2024, p. 234).

For the receiving side the practical consequence is this: the delivery route affects the price and the timescale directly. A project that sends only the string files and a project that sends the whole app do not describe the same work. Making the scope clear from the outset protects both parties.

The book also reports that there are fewer tools specific to app localisation than there are for software localisation (Jiménez-Crespo 2024, p. 229). This means the range of tools may be narrow when you are choosing a supplier; it is worth asking which tool is being used.

The Türkiye context

Android devices hold a high share of the Turkish market, but iOS users stand out markedly in in-app spending. This split turns the question of which platform to localise first into a real decision when the budget is limited. The answer varies with the revenue model of the app.

There is one detail to watch on the language code side. The code used for Turkish is tr, written in its regional form as tr-TR. If folder names and catalogue entries do not match this code, the device never sees the Turkish resources and the app opens in English.

The third issue is case conversion. In Turkish the dotted and dotless i have different capital forms. If the platform libraries take no account of the language setting, button labels are written incorrectly. This is a behaviour that has to be tested separately on both platforms.

Finally there is local legislation. Apps that process personal data are expected to present their privacy notices in Turkish. These texts can be kept in the same file as the interface strings, but the legal approval process is separate and usually takes longer.

What does this mean for you?

If you have an app on two platforms, aim to cover both versions with a single translation order. That is possible, but it takes planning. The sequence below works on most projects.

1. Compare the string lists of the two platforms and mark the shared text.
2. Set up a single translation memory and term list for the shared text.
3. Map the difference in variable notation automatically, at platform or tool level.
4. Count the image and interface files as a line item separate from the string list.
5. Settle the delivery route (files or app package) at the quotation stage.
6. Test the language code and the case behaviour separately on both platforms.

As you adapt this list to your own project, all you need to do is put the scope in writing. You can request a quotation for app localisation and send your questions through our contact page.

Frequently asked questions

Do Android and iOS need separate translations?

The text is mostly the same, and the translation memory can be shared. What differs is the file format, the folder structure and the variable notation. It is the packaging that diverges, not the translation.

Which file holds the Android strings?

The source text is in the strings.xml file in the res/values folder. For each target language, a separate folder such as values-tr and a file with the same name are created.

Which format is used on the iOS side?

Xcode creates a localisation catalogue folder with the .xcloc extension for the selected target languages. The resources to be localised sit in that folder as XLIFF files.

Can the whole app be sent for translation?

Yes. The book defines two routes: sending the exported files, or delivering the app as an APK or APP file. The second route calls for a good knowledge of the development tools.

Sources

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 228–237.
• Android Developers, Localization Guide and Translations Editor documentation (2024).
• Apple Developer, Exporting Localizations documentation (2024).