Managing an app localized into 36 languages: automation is non-negotiable

Most of my 12 iOS apps are localized into 20+ languages. A few go as high as 36. Sending strings out to translators on every release, merging results back, plugging them into the build, and testing: that’s a 2 to 3 day overhead per release, every time.

Over time I built out an automation pipeline. Now a release is a two-hour job. Here’s the toolchain and workflow I use.

The starting point: Localizable.strings isn’t enough

The standard iOS localization format is Localizable.strings files in a per-language directory. It works, but the limits show up fast:

The format is rigid (key-value pairs)
Plurals and gender are painful (stringsdict is a separate file)
Developers have to add keys by hand
No missing-translation detection

On bigger apps I use String Catalog (iOS 16+) or .xcstrings, Apple’s modern format:

Localizable.xcstrings

Edited through the Xcode GUI, native plural/variant/format support, built-in state tracking (needs review, needs translation).

On new projects .xcstrings is the default, and I migrate older projects over.

Automation 1: Translation memory plus version control

The strings file is tracked in git. Every PR that adds new strings gets a CI check:

# Pre-commit hook
localization-check.sh
- Are there any "needs_translation" entries in the .xcstrings files?
- Any missing localizations?
- Are the keys consistent?

The moment you add a new string, CI tells you “this string isn’t translated into 15 languages yet”.

Automation 2: Translation service integration

Tools I’ve used:

POEditor: good for small-to-medium projects. Web UI, GitHub integration, translator assignment.

Lokalise: more enterprise-focused. API-first, strong CI/CD integration.

Crowdin: popular for community translation. Open-source projects love it.

Google Translate / DeepL API: automated first pass. A human translator reviews after.

My workflow with Lokalise:

Developer adds a string, commits to .xcstrings
GitHub Action fires, new strings are uploaded to Lokalise
Translators work in Lokalise (they get an email notification)
When they’re done, a GitHub Action pulls from Lokalise and updates .xcstrings
A PR opens automatically, the developer reviews and merges

End to end that pipeline pushes new strings out to 36 languages in 3 to 4 hours of translator turnaround plus 15 minutes of developer review.

Automation 3: Screenshot generation per locale

The App Store wants separate screenshots for each language. 36 languages * 6 screenshots * 3 devices = 648 screenshots. Doing that by hand is impossible.

I use Fastlane’s snapshot tool:

fastlane snapshot

In the config:

devices([
  "iPhone 15 Pro",
  "iPhone SE (3rd generation)",
  "iPad Pro 12.9-inch"
])
languages([
  "en-US", "tr-TR", "de-DE", "fr-FR",
  "es-ES", "it-IT", "ja-JP", "zh-Hans",
  # ... 36 languages
])

UI tests generate the localized screenshots. An hour of runtime, 600+ screenshots ready.

Automation 4: App Store metadata

The app description, keywords, and what’s new need translating for every language. Fastlane’s deliver tool:

fastlane/metadata/
  en-US/
    description.txt
    keywords.txt
    release_notes.txt
  tr-TR/
    description.txt
    ...
  [36 languages]

Lokalise handles this metadata too. The developer writes the en-US copy, the rest gets auto-translated and human-reviewed.

To release:

fastlane deliver --metadata_only

Metadata for 36 languages uploads to App Store Connect.

Which languages should you support?

36 is not the goal in itself, but some languages belong in. When I’m deciding:

1. App Store audience. How many downloads come from each country in App Store Connect analytics? Add the languages of your top 10 countries.

2. Organic search. How many people search your app name in the App Store, and in which languages?

3. Localization cost. What does translation plus ongoing maintenance cost for one language? Low-return languages lose money.

4. Regional compliance. Some countries require local-language support as a regulatory matter.

The evolution across my apps:
– v1.0: 5 languages (EN, TR, DE, FR, ES)
– v1.5: 15 languages
– v3.0: 36 languages

Every new language gets a translator budget line. Roughly $30/app/month for Lokalise plus translator fees.

Common pitfalls

The mistakes I see most in localization:

1. String concatenation. “Hello ” + userName + “!” and similar. Word order flips in some languages. Always use format strings:

String(format: NSLocalizedString("greeting_format", comment: ""), userName)

2. Forgetting plurals. “%d items” is “1 item” / “5 items” in English, but in Russian it’s “1 товар” / “2 товара” / “5 товаров”. Plural rules are language-specific. Use .stringsdict or .xcstrings plural support.

3. RTL support. Arabic and Hebrew are right-to-left. That isn’t just text alignment, icons, progress bars, and swipe gestures have to flip too. Handle it with UIView.semanticContentAttribute.

4. Number formatting. 1,234.56 in the US. 1.234,56 in Germany. 1 234,56 in France. Use NumberFormatter, don’t concatenate strings.

5. Date/time formatting. DateFormatter’s locale parameter. Day-month order, 12h or 24h.

6. Currency formatting. $100 vs €100 vs ₺100. NumberFormatter.numberStyle = .currency.

Those six patterns are the basic hygiene of a localized app.

Test strategy

The practical way to test a localized app is running different region + language combinations in the simulator:

# Change simulator language
xcrun simctl boot ID
xcrun simctl shutdown ID && xcrun simctl boot ID --locale ar_SA

Or set the runtime language in an Xcode scheme. I don’t run the full UI test suite for every language, but I do smoke-test:

English (baseline)
Turkish (my native language, watched closely)
German (long strings typical)
Japanese (different writing direction)
Arabic (RTL)

Testing those five catches most localization bugs.

Translator management

Translation quality varies. A professional vs an amateur gives you different results.

My approach:

1. Professional for UI strings. Buttons, labels, error messages that the app uses, professional translators. Quality matters.

2. Machine plus review for long-form. App description, help docs. DeepL auto-translate plus a native-speaker review. 80% cost saving.

3. Community for nice-to-have content. For extra language support I accept community (user-submitted) translations. Quality check is there, but speed matters.

Release workflow

For a new iOS release:

Developer adds new strings on a feature branch
CI build check + string extract + Lokalise upload
Translators work in Lokalise (24 to 48 hours)
Auto-merge PR: updated strings land on main
QA team tests the 5 critical languages
Fastlane screenshots (36 languages, about an hour)
Fastlane deliver metadata (36 languages)
App Store Connect submission

Total: 2 to 3 days of prep per release, most of that translator turnaround. Doing it manually end to end would be 2 to 3 weeks.

Takeaway

Localization automation investment is critical for a global iOS app. Past 5 languages, manual management doesn’t scale. Lokalise or POEditor plus Fastlane plus proper string management keeps 36+ languages maintainable.

The initial setup is 1 to 2 weeks of work. After that every new release is a two-hour overhead. If 60 to 70% of your user base is non-English, the ROI on this investment is very high.