Mobile App Localization: iOS and Android Best Practices

Mobile App Localization: iOS and Android Best Practices

Key Takeaways

• iOS uses .strings and .stringsdict files while Android uses strings.xml in res/values-{locale}/ directories
• App Store Optimization (ASO) requires localized metadata — title, description, keywords, and screenshots — for each market
• RTL layout support must be tested across all screens, including custom views and animations
• Over-the-air (OTA) translation updates let you fix translations without submitting a new app version

Platform-Specific Localization

iOS Localization

iOS uses .lproj directories for each locale:

en.lproj/
  Localizable.strings
  Localizable.stringsdict
  InfoPlist.strings
de.lproj/
  Localizable.strings
  Localizable.stringsdict
  InfoPlist.strings

Key files:

• Localizable.strings — key-value pairs for UI text
• Localizable.stringsdict — plural rules (essential for languages with complex plural forms)
• InfoPlist.strings — app name and permission descriptions

Android Localization

Android uses resource directories with locale qualifiers:

res/
  values/strings.xml          (default/English)
  values-de/strings.xml       (German)
  values-ja/strings.xml       (Japanese)
  values-ar/strings.xml       (Arabic)

Android's resource system automatically selects the correct file based on device locale. Use plurals resources for plural forms and string-array for lists.

App Store Optimization (ASO) for Localized Apps

Localize these elements for each target market:

Research keywords per market — do not translate English keywords directly.

RTL Language Support

For Arabic, Hebrew, and other RTL languages:

• Use leading/trailing constraints instead of left/right (iOS)
• Use start/end instead of left/right in layouts (Android)
• Mirror navigation icons (back arrow, list indentation)
• Test bidirectional text (mixed RTL and LTR content)
• Ensure custom views respect layout direction

Over-the-Air Translation Updates

OTA systems allow updating translations without a full app release:

• Fix translation errors immediately
• Add new languages without code changes
• A/B test translations for conversion optimization
• Reduce app update fatigue for users

Mobile App Translation Services: Approaches Compared

Choosing the right mobile app translation service depends on your team size, budget, and quality requirements. Here is a breakdown of the three main approaches.

Manual Translation

Manual translation involves hiring professional translators or agencies to translate your app strings one language at a time. This approach delivers high linguistic quality, especially for marketing copy and user-facing content, but it is slow and expensive. Turnaround times are measured in days or weeks, and coordinating multiple translators across languages introduces project management overhead.

Automated Machine Translation

Standalone machine translation services (Google Translate API, DeepL API, Azure Translator) offer speed and low cost. They work well for generating first drafts of UI strings and documentation, but the output lacks product context. A button label like "Set" might be translated as a noun (a collection) rather than a verb (to configure) without awareness of where the string appears in the UI. Automated MT requires human post-editing before shipping to production.

Platform-Based App Translation Services

Platform-based app translation services combine automation with workflow management. Instead of managing translators and MT engines separately, a platform handles the full pipeline: string extraction, machine translation, human review routing, translation memory, and delivery back to your codebase.

Better i18n is built for this model. It provides an Expo SDK (@better-i18n/expo) for React Native apps, enabling OTA translation updates without redeploying through the App Store or Google Play. The platform's AI translation engine understands product glossary and UI context, producing translations that are aware of where each string appears in your app. Translations are delivered via CDN with 300+ edge locations and sub-50ms load times, so users see updated translations instantly.

For teams evaluating app translation services, the key question is whether you need a one-time translation vendor or an ongoing translation pipeline that keeps pace with your release cycle. If your app ships new features regularly, a platform approach eliminates the coordination overhead that slows down manual and standalone MT workflows.

Common Mobile Localization Mistakes

1. Hardcoded strings in code instead of resource files
2. Fixed-width UI elements that break with longer translations
3. Ignoring plural forms — many languages have more than singular/plural
4. Untranslated screenshots in app store listings
5. Missing RTL testing for Arabic and Hebrew markets

FAQ

How many languages should I launch with? Start with your top 5-10 markets by revenue or user base. Common first targets: English, Spanish, French, German, Japanese, Chinese, Korean, Portuguese.

Should I use machine translation for app strings? Machine translation can provide initial drafts, but UI strings require human review for context accuracy. Short strings without context are particularly challenging for MT.

How do I handle dynamic content localization? Use server-side localization for dynamic content (push notifications, in-app messages). Client-side localization handles static UI. A TMS can manage both workflows.

What about date, time, and number formatting? Use platform formatters (DateFormatter on iOS, DateFormat on Android) with the device locale. Never format dates or numbers manually.