How to localize an iOS app into 40+ languages with String Catalogs (.xcstrings)

To localize an iOS app into 40+ languages, keep every user-facing string in Xcode String Catalogs (Localizable.xcstrings and InfoPlist.xcstrings), let Xcode extract them automatically, handle plurals in the catalog and formatting with FormatStyle, test with pseudolanguages and right-to-left layouts, then translate with machine translation for speed and human review where it matters. Finish with the App Store product page, which is localized separately in App Store Connect. This is how Develak ships its own apps in up to 44 languages.

Key takeaways

• String Catalogs (.xcstrings, Xcode 15 and later) replace .strings and .stringsdict: one file per table, with plurals and device variations built in.
• Never build sentences by concatenation or format dates and numbers by hand.
• Localize InfoPlist.xcstrings too: permission prompts and the app name are part of the first impression.
• Test with pseudolanguages before paying for a single translation.
• Localize the App Store product page (name, subtitle, keywords, description, screenshots) for each market.
• Machine translation, LLMs included, is a good first pass; have people review the strings that sell, charge or warn.

Why localize an iOS app?

The App Store is available in 175 countries and regions, and people search, read reviews and decide in their own language. A localized app with a localized product page competes for local keywords and feels trustworthy in markets where most English-only apps don’t bother. Users can also choose a language per app in iOS Settings, so each language you add is used by people who explicitly want it.

Once the process exists, each extra language costs far less than the first. Our most recent apps ship in 44 languages, including Arabic, Hebrew and Urdu (right-to-left) and Indian languages such as Hindi, Bengali, Tamil and Telugu. That is only sustainable because the steps below are routine.

String Catalogs in five minutes

A String Catalog is a JSON file with the .xcstrings extension, introduced in Xcode 15, that stores every string of a table and all its translations. Add one named Localizable to your target and build: Xcode extracts strings from SwiftUI views, String(localized:), LocalizedStringResource and NSLocalizedString. Each entry shows a state (New, Needs Review, Translated, Stale) and a comment for translators. Existing .strings and .stringsdict files can be migrated from the file’s context menu.

// Extracted automatically into Localizable.xcstrings
Text("Take your medication")

// A comment gives translators the context they need
Text("Open", comment: "Button: opens the selected bottle's details")

// Outside SwiftUI views
let title = String(localized: "Cellar", comment: "Tab title for the list of bottles")

Comments are the cheapest quality improvement in localization: “Open” can be a verb or an adjective, and “Archive” a noun or an action. Xcode 26 can also draft translator comments with an on-device model and generate type-safe Swift symbols for strings you add manually to the catalog. In Swift packages, set defaultLocalization in Package.swift and look strings up in Bundle.module.

Plurals and device variations

Write the sentence once with interpolation, then choose Vary by Plural on that key in the catalog. Xcode shows exactly the plural categories each language needs:

// Catalog key: "%lld reminders" → Vary by Plural
Text("\(count) reminders")

A string with two numbers (“%lld photos in %lld albums”) can vary on each one independently. Vary by Device handles wording that depends on the hardware, such as “Tap to start” on iPhone and “Click to start” on Mac.

InfoPlist.xcstrings: permission prompts and the app name

Add a second String Catalog named InfoPlist to the target and Xcode fills it with the localizable keys of Info.plist: the Home Screen name (CFBundleDisplayName) and every purpose string, from NSCameraUsageDescription and NSMicrophoneUsageDescription to NSHealthShareUsageDescription. A permission prompt is the moment you ask for trust, and an English prompt in a French app looks unfinished at exactly that moment. App Review also reads these strings under guideline 5.1.1, so their translations should stay precise.

Two more places are easy to forget: App Shortcuts phrases live in AppShortcuts.xcstrings, and widget extensions need their strings available in the extension target.

Dates, numbers and units: let FormatStyle do it

Date order, 12- or 24-hour clocks, decimal separators, currency placement, the first day of the week and the measurement system all change with the user’s region. Never hard-code "MM/dd/yyyy" or a currency symbol:

// Weekday and time, in the user's language and clock format
Text(dose.scheduledAt, format: .dateTime.weekday(.wide).hour().minute())

// Currency with the right symbol and separators
Text(price, format: .currency(code: "EUR"))

// Kilometers or miles, depending on the user's region
Text(distance, format: .measurement(width: .abbreviated, usage: .road))

// "Pillio, Seizly, and ApexLap" or "Pillio, Seizly et ApexLap"
Text(appNames.formatted(.list(type: .and)))

Sort user-visible lists with localizedStandardCompare and search with localizedStandardContains, so accents and case behave as people expect.

Right-to-left languages: Arabic, Hebrew, Urdu

SwiftUI mirrors layouts automatically when you use leading and trailing instead of left and right. Directional SF Symbols flip on their own; for your own directional images, opt in explicitly. Do not mirror what isn’t directional: logos, photos, checkmarks. Check the result in a preview:

Image("swipe-hint")
    .flipsForRightToLeftLayoutDirection(true)

#Preview("Arabic, right-to-left") {
    ContentView()
        .environment(\.locale, Locale(identifier: "ar"))
        .environment(\.layoutDirection, .rightToLeft)
}

Test before you translate: pseudolanguages

In the scheme editor (Run › Options › App Language), Xcode offers pseudolanguages that reveal localization bugs with no translation at all. Turn on “Show non-localized strings” in the same panel to spot hard-coded text.

UI tests can launch the app in any language, which is also how localized App Store screenshots can be automated:

let app = XCUIApplication()
app.launchArguments += ["-AppleLanguages", "(de)", "-AppleLocale", "de_DE"]
app.launch()

Localize the App Store product page too

The binary and the product page are localized separately. The “Languages” line of your listing comes from the app bundle; everything else is set per localization in App Store Connect, which accepts metadata in roughly 40 languages and regional variants:

• Name and subtitle (30 characters each), promotional text, description and What’s New.
• Keywords (100 characters per localization), researched in each language rather than translated: a French user looking for a pill reminder may type “pilulier”, a word no translation of “pill reminder” produces.
• Screenshots and app previews with translated captions; without them, the primary language’s are shown. Arabic and Hebrew screenshots should show the mirrored interface.
• In-app purchase display names, descriptions and subscription group names.

Localized keywords and screenshots are core App Store Optimization work, which is why our ASO service treats each market separately.

Human, machine or both?

Large language models now translate interface strings well when they get context: the translator comment, the surrounding screen, a glossary of product terms. They still stumble on register (formal or informal “you” in French, German or Spanish), gender agreement, length, and placeholders that must survive untouched. Our rule: machine translation for the first pass on everything, then human review for onboarding, the paywall and subscription terms, permission prompts, App Store metadata and anything medical, legal or safety-related. Brand names such as Pillio or Seizly are marked “Don’t translate”, and TestFlight builds go to native speakers before release.

Our tool: Xlocalize for .xcstrings files

Localizing a catalogue of 34 apps pushed us to build our own Mac app. Xlocalize opens a .xcstrings file, lets you pick target languages and translates with OpenAI, Anthropic Claude or Google Gemini, using your own API key stored in the macOS Keychain. It preserves plurals, device variations and substitutions, sends per-key comments as context, and flags placeholder mismatches and missing translations before they reach a build.

A localization workflow checklist

1. Internationalize the code: no hard-coded strings, FormatStyle everywhere, leading and trailing layouts, flexible sizes and Dynamic Type.
2. Create Localizable, InfoPlist and, if needed, AppShortcuts catalogs, then build to extract.
3. Add comments to ambiguous strings and mark brand names “Don’t translate”.
4. Set up plural and device variations.
5. Test with pseudolanguages and right-to-left.
6. Translate: machine first pass, human review of critical strings.
7. Check placeholders and truncation in every language on the smallest supported iPhone.
8. Localize App Store metadata, keywords, screenshots and in-app purchase names.
9. Ship to native speakers through TestFlight.
10. Every release, translate new and stale strings before you submit.

Common pitfalls

• Concatenation. "Hello " + name breaks word order; use one localized string with interpolation.
• One key, two meanings. Reusing “Open” for a verb and an adjective forces a bad translation in half the languages.
• Argument order. Translators may need to reorder values; positional specifiers such as %1$@ and %2$lld make that possible.
• Text inside images, which no String Catalog can translate.
• Fixed widths and single-line labels that collapse in German.
• Accessibility labels. VoiceOver reads .accessibilityLabel text aloud; it is extracted like any other string, so check that it is translated rather than left in English.
• Server-side text: push notifications and e-mails need localization too, for example with loc-key in the notification payload.
• Stale strings left untranslated after a redesign.

If you would rather hand the whole process to a team that does it every week, our app localization service covers the code, the translations, the review and the App Store listing.

FAQ