Apple String Catalogs (.xcstrings): Modern iOS Localization and Migration Strategy

If you are localizing an iOS, macOS, watchOS, or tvOS app in 2026, Apple String Catalogs are usually the right default.

For years, Apple localization meant living with two parallel systems: .strings for straightforward text and .stringsdict for plural and variation logic. That split worked, but it forced Apple teams to manage multiple file types, separate editing experiences, and migration headaches whenever strings became more complex.

String Catalogs (.xcstrings) are Apple’s answer to that fragmentation. They unify static strings, plural behavior, variation support, and translation state inside a single modern format that Xcode understands natively.

For Apple teams, the real value is not just that .xcstrings is newer. It is that it fits better with modern app development, where strings are extracted continuously, reviewed collaboratively, and expected to behave across iPhone, iPad, Mac, watchOS, tvOS, and Vision Pro.

What an XCStrings file changes operationally

An .xcstrings file is a modern, structured JSON catalog that manages all your translations for all supported languages in one place. Unlike the old system, which required a separate file for every language, String Catalogs act as a central catalog for your app’s localization state.

That centralized structure is a major workflow improvement. Instead of maintaining scattered locale files, teams can review translation status, variation rules, and stale keys in one place.

Why automatic extraction matters

One of the most powerful features of String Catalogs is automatic extraction. Xcode now scans your SwiftUI views and LocalizedStringResource calls during the build process.

If you write Text("Welcome") in your code, Xcode automatically adds the “Welcome” key to your catalog. If you delete the code, Xcode marks the key as stale, helping you keep your translation files lean and clean.

For active product teams, this matters more than it first appears. Automatic extraction reduces the drift between code and localization resources, which is a common source of missing keys and stale copy in long-lived apps.

Advanced Features: More than Just Text ✨

The .xcstrings format handles linguistic complexity that previously required hours of manual XML configuration.

1. Built-in Pluralization

You no longer need a separate .stringsdict file. You can right-click any key in the Xcode editor and choose “Vary by Plural.” This allows you to define forms like one and other directly in the visual editor.

2. Device Variations

Sometimes, “Tap to start” is right for an iPhone, but “Click to start” is better for a Mac. XCStrings allows you to Vary by Device, providing different strings for:

• iPhone / iPad
• Mac
• Apple Watch / Apple TV
• Apple Vision Pro

3. Translation State Tracking

The format includes built-in metadata to track the status of your translations:

• New: Recently extracted and needs translation.
• Translated: Ready to go.
• Stale: No longer found in your source code.
• Reviewed: Manually verified by a team member.

That review metadata makes String Catalogs feel closer to a lightweight translation management layer than to a simple resource file.

Anatomy of the JSON Structure

While Xcode provides a beautiful GUI, the underlying JSON is clean and version-control friendly:

{
  "sourceLanguage" : "en",
  "strings" : {
    "welcome_header" : {
      "extractionState" : "manual",
      "localizations" : {
        "es" : {
          "stringUnit" : {
            "state" : "translated",
            "value" : "Bienvenido"
          }
        }
      }
    }
  },
  "version" : "1.0"
}

That underlying JSON also makes .xcstrings easier to process programmatically than the older split between .strings and .stringsdict.

Why generic translation tools struggle with XCStrings

String Catalogs may be JSON underneath, but they are not generic translation JSON. Device variations, extraction state, translator review markers, and structured localizations all live inside the same file.

That means tools built for plain key-value translation often miss what makes .xcstrings useful in the first place. They may translate text, but they do not reliably preserve the operational metadata Apple teams depend on.

Migration Pain Points Teams Should Expect

The migration from legacy Apple localization formats is usually worth it, but it is not completely frictionless.

Mixed legacy projects

Older apps may still contain years of .strings and .stringsdict conventions, translator notes, and team habits. Migration works best when teams audit naming and duplication before converting everything at once.

Source-string churn

Automatic extraction is powerful, but it also means string management is tied more closely to source-code changes. Teams need lightweight review discipline so catalogs do not fill with noisy or temporary keys.

Cross-platform thinking

If your organization also ships Android, Flutter, React Native, or web clients, .xcstrings is only one piece of the overall localization strategy. Apple teams often need a clear bridge between String Catalogs and formats such as Flutter ARB, i18next JSON v4, or XLIFF.

Why upgrade to String Catalogs?

• Single Source of Truth: Manage all languages in one file.
• Visual Editor: No more syntax errors from missing semicolons in .strings files.
• Safety: Integration with Swift symbols ensures you don’t have typos in your keys.
• Backward Compatibility: Xcode compiles .xcstrings into the old formats at build time, so your app still runs on older OS versions.

XCStrings vs. Other Modern Localization Formats

Apple String Catalogs are not just “JSON for Apple.” They are tightly integrated with Xcode and Apple platform conventions.

That creates a different tradeoff from other formats:

• compared with ARB, .xcstrings is more Apple-native and editor-driven
• compared with i18next JSON v4, it carries more platform-specific state and device variations
• compared with XLIFF, it is less of an interchange format and more of a first-party app-development format

If your team lives primarily in Xcode, that specialization is a strength. If you are trying to unify many platforms into one translation exchange format, you may still need XLIFF or another cross-platform layer somewhere in the pipeline.

Getting started 🚀

To migrate your existing project, right-click your legacy .strings files in the Project Navigator and select “Migrate to String Catalog…”. Xcode will handle the conversion of both your strings and your pluralization logic automatically.

For a full breakdown of the new API, visit the Apple Developer Documentation on String Catalogs.

Where MetalGlot fits Apple workflows

The .xcstrings catalog is powerful because it keeps all your translations in one place, but at scale it still creates operational work.

MetalGlot fits Apple workflows by working with the catalog structure directly rather than flattening it into generic text.

• JSON-safe processing: Update only the keys that need translation without damaging the catalog structure.
• Privacy-first operation: Keep proprietary product copy and unreleased features on your own hardware.
• Context-aware translation: Preserve the UI meaning behind common Apple platform terms.

Final take

Apple String Catalogs are a meaningful upgrade because they align localization with the way Apple apps are actually built today: continuously, visually, and across multiple device classes.

For teams already committed to the Apple ecosystem, .xcstrings is the right default. The main remaining challenge is operational: translating and reviewing those catalogs efficiently without losing the platform-specific advantages that make them valuable in the first place.