Xcode String Catalogs (.xcstrings)

Format, editor, and translation workflow for Apple's modern iOS / macOS localization file.

String Catalogs (.xcstrings) are Apple's modern localization format, introduced in Xcode 15 (June 2023). A String Catalog is a JSON-based file that holds every localizable string for an app — across all languages, with pluralization and device variations — in a single file. It replaces the older pair of Localizable.strings (key/value tables) and Localizable.stringsdict (plurals as XML property lists) for new projects. At build time Xcode still compiles String Catalogs into the same runtime resources, so APIs like NSLocalizedString and String(localized:) are unchanged — String Catalogs are a better authoring surface, not a runtime change.

Key facts

What it is: JSON-based localization file (one file per app)
Standard body: Apple
Introduced: Xcode 15 (June 2023)
File extension: .xcstrings
Encoding: UTF-8
Used by: iOS, macOS, watchOS, tvOS, visionOS apps
Replaces: .strings + .stringsdict (still supported, but legacy)
Plurals: CLDR categories — one / few / many / other / zero / two

What an .xcstrings file looks like

A String Catalog is a JSON document with a strings object keyed by your source-language string. Each entry holds a localizations map — one per language — with optional variations for plurals, device classes, or width modifiers. Plain strings use stringUnit; varying strings nest variations inside.

{
  "sourceLanguage" : "en",
  "strings" : {
    "greeting" : {
      "comment" : "Welcome message on the home screen",
      "localizations" : {
        "en" : {
          "stringUnit" : { "state" : "translated", "value" : "Hello" }
        },
        "de" : {
          "stringUnit" : { "state" : "translated", "value" : "Hallo" }
        }
      }
    },
    "houses" : {
      "comment" : "Pluralized house count",
      "localizations" : {
        "en" : {
          "variations" : {
            "plural" : {
              "one" : { "stringUnit" : { "state" : "translated", "value" : "%lld house" } },
              "other" : { "stringUnit" : { "state" : "translated", "value" : "%lld houses" } }
            }
          }
        },
        "de" : {
          "variations" : {
            "plural" : {
              "one" : { "stringUnit" : { "state" : "translated", "value" : "%lld Haus" } },
              "other" : { "stringUnit" : { "state" : "translated", "value" : "%lld Häuser" } }
            }
          }
        }
      }
    }
  },
  "version" : "1.0"
}

Each stringUnit tracks a state — typically new, translated, needs_review, or stale — so Xcode can show translation progress per-language and per-key.

How is xcstrings different from .strings and .stringsdict?

In the legacy iOS / macOS approach, every language had a pair of files:

Localizable.strings for plain key/value pairs
Localizable.stringsdict for plurals (XML property lists)

That pair multiplied with each new language — a 10-language app meant 20 files to maintain, with no per-key status tracking and no easy diff. String Catalogs collapse all of that into one file: every key has an entry with a localizations map keyed by language, every plural rule lives next to the key it modifies, and Xcode shows translation status per-language as you work.

Migration is built in. In Xcode, right-click a .strings or .stringsdict file in the Project Navigator and choose "Migrate to String Catalog" — Xcode reads the existing content and produces an equivalent .xcstrings, preserving translations and plural rules.

Editing .xcstrings files

For solo developers and small projects, Xcode's built-in String Catalog editor is excellent: side-by-side language columns, per-key state, and inline plural variation editing. It does most of what you need without leaving Xcode.

For team workflows — multiple translators, review approval, brand-voice consistency, continuous translation against a shared glossary — a translation management system is the better fit. Common options:

Translation management systems (TMS): Locize, Phrase, Crowdin, Lokalise — import .xcstrings directly, edit translations in a CAT-style UI, export back to .xcstrings for the build
Xcode's String Catalog editor: built-in, free, fine for solo work
Text editors: only for spot fixes; the JSON nesting makes hand-editing tedious at scale

Common .xcstrings workflows

New iOS / macOS app. Start with String Catalogs from day one — Xcode 15+ scaffolds them by default in new project templates.
Migrating from .strings / .stringsdict. Right-click → Migrate to String Catalog. Xcode handles the conversion preserving translations and plural rules.
Sending translation work to a TMS or agency. Export the .xcstrings from Xcode (or commit it to source control) and import it into your TMS. Translators work in a CAT UI, not in JSON. Export back to .xcstrings when done.
Continuous localization. Wire your TMS into your CI/CD so new keys flow into the TMS automatically (via saveMissing or similar). New translations sync back into the .xcstrings on the next build.

How to edit .xcstrings files in Locize

Locize imports and exports String Catalogs natively, so you can edit translations in a CAT-style UI without leaving the format Xcode expects:

Get started
Import your .xcstrings file
Edit translations in the CAT view with translation memory, glossary, and style guide applied automatically
Use bulk actions for AI / machine translation, then route results through a review workflow
Export back to .xcstrings — or convert to XLIFF, JSON, YAML, or any other supported format

Frequently asked questions

What is an .xcstrings file?

An .xcstrings file (String Catalog) is Apple's modern localization format, introduced in Xcode 15 (June 2023). It is a JSON-based file that holds all of an app's localizable strings — including pluralization variations and device-specific variations — for every supported language in a single file. It replaces the older pair of .strings (string-table) and .stringsdict (plurals) files for new projects.

How is xcstrings different from .strings and .stringsdict?

In the legacy approach, each language had its own Localizable.strings (key/value pairs) and Localizable.stringsdict (plurals as XML property lists). In String Catalogs, every language's text — including plurals, device variants, and substitutions — lives in one .xcstrings file. Xcode tracks translation status (translated, needs review, stale) per-key, and shows a diff-friendly editor instead of multiple text files.

What does Xcode do with .xcstrings files at build time?

Xcode compiles String Catalogs into the same .strings / .stringsdict resources at build time, so the runtime APIs (NSLocalizedString, String(localized:), AttributedString) are unchanged. From a developer's perspective the format is just a better authoring surface; the runtime behavior is identical.

Can I migrate existing .strings and .stringsdict to xcstrings?

Yes. In Xcode, right-click a .strings or .stringsdict file in the Project Navigator and choose "Migrate to String Catalog". Xcode reads the existing content and produces an equivalent .xcstrings, preserving translations and plural rules. Apple recommends this for new projects targeting Xcode 15+.

How do I edit .xcstrings files outside Xcode?

String Catalogs are JSON, so any editor opens them — but they are not pleasant to hand-edit at scale because of their nested variation structure. For team workflows, use a translation management system that imports .xcstrings natively. Locize supports import and export, so you can edit translations in a CAT-style UI with translation memory and glossary, then export back to .xcstrings for your build.

Does .xcstrings handle plurals correctly?

Yes — String Catalogs use CLDR plural categories (one, few, many, other, zero, two) per language, the same rules iOS already used in .stringsdict. The advantage is that all variations live in one place per key, instead of split between .strings and .stringsdict.

Should I still use .strings for new iOS apps?

Not for new projects. If you target Xcode 15 / iOS 17 or later, String Catalogs are the recommended format. .strings files are still supported and necessary for some legacy code and SDKs, and Xcode still ships them at build time, but new development should standardize on .xcstrings.

Translate your .xcstrings — without leaving the format.

Import, edit with translation memory, glossary and AI, review, and export — back to .xcstrings or to any other format.

Start free trial