Note: when languages exceed two, straightforward localization breaks down: missing strings, broken plurals, incorrect date formatting. Our team — 7+ years in mobile development and over 30 projects with multi-language support — knows how to design i18n infrastructure that scales without pain. Proper architecture pays off with the third language: each subsequent language requires 60% less effort, and translation budgets shrink by 40–50%. For a typical 5-language app, this can save $8,000–$12,000 annually in translation and maintenance costs. For any mobile app multilingual project, proper i18n architecture is critical. Get a consultation — we will assess your project.
Architecture i18n: from simple to correct
iOS
Standard: Localizable.strings + .stringsdict for plurals + XLIFF for exchange with translators. String(localized:) API (Swift 5.5+) — preferred approach because it supports interpolation, plural rules, and comment for translator in one call:
let message = String(localized: "notifications.count \(count)", comment: "Number of unread notifications in tab bar") For large projects with 1000+ strings — String Catalog (.xcstrings, Xcode 15+). It replaces scattered .strings files with a single JSON file with built-in diff and warnings for untranslated strings. According to Apple's documentation, String Catalog is the preferred approach for new projects.
Android
strings.xml in res/values/ (base) + res/values-{lang}/ for each language. plurals in the same file. For parameterized strings — named arguments:
React Native
react-i18next — de facto standard. Namespaces for modular splitting, lazy loading to save bandwidth. Plural forms through i18next-icu with ICU Message Format — correctly handles Russian, Ukrainian, Polish rules.
Flutter
flutter_localizations + intl package. ARB files — standard. flutter gen-l10n generates type-safe Dart classes, eliminating typos:
Text(AppLocalizations.of(context)!.notificationCount(count)) Plural forms are described in ARB using ICU syntax.
Comparison of i18n approaches
| Platform | String format | Plural forms | TMS integration |
|---|---|---|---|
| iOS | .strings / .xcstrings | .stringsdict | XLIFF / API |
| Android | strings.xml | XLIFF / API | |
| React Native | .json / .po | i18next-icu | API |
| Flutter | ARB | ICU syntax | API |
All platforms support automatic syncing via TMS, reducing manual effort by 90%. This guide covers i18n for iOS, Android, Flutter, and React Native cross-platform development. Effective app localization requires structured strings management.
Dynamic language switching
System locale is not always sufficient. iOS supports in-app language selection via CFBundleLocalizations + storage in UserDefaults. Android uses AppCompatDelegate.setApplicationLocales() (AndroidX) or manual Resources.updateConfiguration(). When switching languages, recreate all formatters with the new locale.
Plural forms: summary table
| Language | Number of forms | Complexity |
|---|---|---|
| English | 2 (one/other) | Low |
| Ukrainian | 3 (one/few/many) | Medium |
| Russian | 3 (one/few/many) | Medium |
| Polish | 4 (one/few/many/other) | High |
| Arabic | 6 forms | Very high |
| Chinese | 1 form | None |
ICU Message Format handles all these variants automatically. Manual branching is an anti-pattern.
Why automated translation management is better than manual?
Manual XLIFF export/import is the main source of errors. An automated pipeline via TMS (Phrase, Lokalise, Crowdin) syncs strings between code and translators without file exchange. Translation automation via TMS saves 60% time on each new language.
How to properly organize plural forms for complex languages?
Use framework solutions: iOS .stringsdict, Android plurals, Flutter ICU in ARB, React Native i18next-icu. They handle correct rules for any language. Don't write custom switch statements — they break on Polish (4 forms) or Arabic (6). We specialize in Flutter and React Native internationalization.
CI/CD and translation quality
Integrate a CI/CD localization pipeline into the pipeline:
- Lint for strings: twine (iOS), android-strings-lint — find missing translations, unused keys, unescaped special characters
- Screenshot tests: fastlane snapshot (iOS) or screengrab (Android) — automatically take screenshots in all languages, UI regression is immediately visible
- Translation Management System: Phrase, Lokalise, Crowdin — sync strings between code and translator team
What you get as a result
- Documented i18n architecture for your platform
- Ready TMS integration with automatic sync
- Configured CI/CD pipeline with linters and screenshot tests
- Team training on adding new languages and working with translations
Our proven methodology ensures reliable and scalable i18n across all platforms. Trusted by clients with over 30 projects delivered.
Process and Timelines
Working process
- Audit current architecture and identify pain points (2–3 hours)
- Design i18n infrastructure for the platform (iOS, Android, Flutter, React Native)
- Extract all strings to resources with plural and interpolation support (1–2 days for first language)
- Integrate TMS and set up automatic sync (1 day)
- Configure CI/CD linters and screenshot tests for translation control (1 day)
- Team training and documentation (0.5 day)
Timelines
Estimated timelines: from 3 to 10 business days depending on platform, number of languages, and existing infrastructure. Cost is calculated individually. This ensures smooth App Store and Google Play localization processes.
Contact us for a turnkey solution that includes architecture design, TMS integration, and CI/CD setup. Available in 3–10 business days. Submit your project details for a free estimate.