🎉 v1.0

Get started

  • Welcome
  • Documentation
  • Pricing
    Soon

Tools

  • I18n MCP
  • CLI
  • CI/CD Integrations
  • Compiler
    Alpha
  • Connect Your Engine

Resources

  • Languages
  • LLM Models
  • Guides

Company

  • Enterprise
  • CareersHiring!
Dashboard

Localization

  • Overview
  • Translation API
  • Web App
  • Mobile App
  • Emails
  • Static Content (e.g. .md, .json)
  • CI/CD Workflows

Mobile App Localization

Max PrilutskiyMax Prilutskiy·Updated 1 day ago·3 min read

The Lingo.dev CLI translates native mobile resource files - Xcode .strings, Android XML, Flutter ARB, and React Native JSON - through a configured localization engine. Each platform has a dedicated bucket type that understands the file format, preserves structure, and handles plurals natively.

Platform Overview#

PlatformNative formatCLI bucketTypical file path
iOS (Xcode).stringsxcode-strings[locale].lproj/Localizable.strings
iOS (Xcode).stringsdictxcode-stringsdict[locale].lproj/Localizable.stringsdict
iOS (Xcode).xcstringsxcode-xcstringsLocalizable.xcstrings
Androidstrings.xmlandroidapp/src/main/res/values-[locale]/strings.xml
Flutter.arbflutterlib/l10n/app_[locale].arb
React Native.jsonjsonsrc/locales/[locale].json

Prerequisites#

Every CLI run sends content through a localization engine - the configuration that determines which LLM model, glossary, brand voice, and instructions apply. Create one in the Lingo.dev dashboard and generate an API key.

Configure Your Platform#

Xcode supports three localization formats. Use the one that matches your project setup.

String Catalogs (.xcstrings) - the modern Xcode format introduced in Xcode 15. A single JSON file contains all locales, and Xcode updates it automatically when you add new strings. The CLI mutates this file in place - no [locale] placeholder needed.

json
{
  "$schema": "https://lingo.dev/schema/i18n.json",
  "version": "1.15",
  "locale": {
    "source": "en",
    "targets": ["es", "fr", "de", "ja"]
  },
  "buckets": {
    "xcode-xcstrings": {
      "include": ["MyApp/Localizable.xcstrings"]
    }
  }
}

Legacy .strings files - one file per locale in [locale].lproj/ directories. If your project also uses .stringsdict for plurals, add both buckets.

json
{
  "$schema": "https://lingo.dev/schema/i18n.json",
  "version": "1.15",
  "locale": {
    "source": "en",
    "targets": ["es", "fr", "de", "ja"]
  },
  "buckets": {
    "xcode-strings": {
      "include": ["MyApp/[locale].lproj/Localizable.strings"]
    },
    "xcode-stringsdict": {
      "include": ["MyApp/[locale].lproj/Localizable.stringsdict"]
    }
  }
}

See Apple's localization documentation for setting up Xcode's i18n infrastructure.

Running Translations#

Translate all resource files in one command:

bash
npx lingo.dev@latest run

The CLI reads your source locale files, computes what changed since the last run using the lockfile, translates only the delta, and writes results to target locale files.

Target a specific platform when your project contains multiple resource types:

bash
npx lingo.dev@latest run --bucket android
npx lingo.dev@latest run --bucket xcode-xcstrings

Plurals and Platform Conventions#

Each mobile platform handles plural forms differently - iOS uses .stringsdict or String Catalog rules, Android uses <plurals> XML elements, and Flutter uses ICU MessageFormat in ARB files. The CLI preserves each platform's native plural structure during translation and generates the correct plural categories for each target locale.

Translator notes

Mobile strings are often short and context-dependent. Use translator notes in Xcode .xcstrings files to give the localization engine context about where a string appears - "button label in checkout flow" translates differently than "navigation menu item."

Next Steps#

Supported Formats
Full reference for all mobile file formats and bucket types
Glossaries
Lock brand names and technical terms from translation
CI/CD Workflows
Automate mobile translations on every push
Key Locking
Copy specific values without translating them

Was this page helpful?