The Complete Guide to Xcode String Catalogs (.xcstrings)

Last updated: February 25, 2026
By: Bill Richards

Xcode String Catalogs (.xcstrings) are Apple’s modern localization system introduced in Xcode 15. If you're still maintaining .strings and .stringsdict files manually, you're using a workflow Apple is actively replacing.

This guide explains:

• What an .xcstrings file actually is
• Why Apple introduced string catalogs
• How extraction works
• How to migrate safely from .strings
• How to handle plurals correctly
• How to manage catalogs in Git and CI without creating chaos

This is a developer-first, practical breakdown — not a marketing overview.

What Is a String Catalog?

A String Catalog is an Xcode-managed localization table stored in a single .xcstrings file.

Instead of separate .lproj folders with individual .strings files per language, a catalog:

• Stores all languages in one structured file
• Supports plurals and variations natively
• Preserves translation metadata and comments
• Displays translation progress directly in Xcode

It is JSON-backed, but it is not meant to be hand-edited. Xcode is the canonical editor.

String Catalogs replace the fragmented .strings + .stringsdict workflow with a unified system that Xcode controls.

Why Apple Introduced .xcstrings

The legacy model had real friction:

• .strings handled flat key/value pairs
• .stringsdict handled plurals separately
• Extraction could drift from source code
• Merge conflicts were common
• Translation progress was opaque

String Catalogs unify all of that into a single structured system managed by Xcode.

This shift is architectural. Apple is consolidating localization under a single format that supports plurals, variations, extraction, and status tracking inside the IDE.

How String Catalog Extraction Works

When you add a .xcstrings file and build your project:

1. Xcode scans Swift, SwiftUI, Interface Builder, and other localizable resources.
2. It extracts discovered strings into the catalog.
3. It merges new keys into the existing catalog.
4. It tracks translation state in the editor.

You no longer manually manage per-language files.

This reduces:

• Forgotten keys
• Orphaned translations
• Runtime missing-string surprises

For a deeper workflow breakdown, see:
Native iOS Localization Workflows with XCStrings and XCLoc

Plurals and Variants

Previously, plurals required .stringsdict. With String Catalogs, plural logic is integrated directly into the catalog editor.

This means:

• Proper locale-aware plural rules
• Cleaner substitution handling
• No parallel plural files to maintain

If you’re mixing .strings and .stringsdict, migration alone simplifies your localization architecture.

Migration From .strings to .xcstrings

Migration does not have to be all-or-nothing.

A practical path:

1. Add a catalog file.
2. Build once so Xcode populates it.
3. Migrate one module or table at a time.
4. Validate runtime behavior.
5. Gradually remove legacy .strings files.

For a detailed walkthrough:
Migrate From Legacy .strings to String Catalog in Xcode

Translation Comments Matter

Short UI strings are ambiguous without context.

Comments improve translation quality dramatically. Without them, translators guess.

If you're not leveraging comments properly, you are degrading localization accuracy.

See:
Accurate Translation Comments in String Catalogs with Xcode 26

Exporting and Importing Localizations

The supported exchange format for translators is .xcloc.

To export:

• Product → Export Localizations…

To import:

• Product → Import Localizations…

Xcode generates and consumes structured localization bundles safely.

Treat .xcstrings as an Xcode-owned artifact.
Use .xcloc as the boundary for automation and translator exchange.

Git and CI Considerations

This is where most teams get into trouble.

1. Large Diffs

A catalog stores an entire table in one file.
Small string changes can produce large diffs.

That is normal.

What causes chaos is not the format — it’s workflow.

2. Do Not Reformat .xcstrings

Do not:

• Run JSON prettifiers
• Run auto-formatters
• Let AI agents rewrite the file
• Treat it like arbitrary JSON

.xcstrings is structured data owned by Xcode.
External rewrites are the primary cause of noisy diffs and broken metadata.

3. Separate Localization PRs

Do not mix:

• Feature logic
• Refactors
• Localization extraction churn

Keep localization changes scoped and review them intentionally.

4. Standardize Xcode Versions

Minor Xcode updates can alter serialization details.

If your team uses inconsistent Xcode versions, diffs grow unnecessarily.

Multiple Catalogs and Tables

You can create multiple .xcstrings files.

Each catalog represents a table.

Use multiple catalogs when:

• Modules ship independently
• Ownership boundaries differ
• Large apps require separation

This keeps catalogs manageable without fragmenting language data.

Strategic Language Expansion

Once your catalog is stable, the next question is:

Which languages should you add?

Localization should follow demand and ROI, not guesswork.

See:
How to Choose Languages to Localize First

TestFlight Release Notes

Localization doesn’t stop at in-app UI.

TestFlight “What’s New” release notes can also be localized and automated.

See:
Auto-Localized TestFlight Notes with String Catalog

FAQ

Is .xcstrings mandatory?

No. But it is the recommended path for modern Xcode projects.

Can I still use .strings?

Yes. But you lose unified plural handling, structured metadata, and IDE translation tracking.

Should I hand-edit .xcstrings?

No. Let Xcode manage structure.
Use export/import workflows for automation.

Final Thoughts

String Catalogs are not just a file format.

They are:

• A unified localization system
• A structured plural model
• A translation-aware IDE workflow
• Apple’s long-term direction

Adopting .xcstrings early gives you:

• Cleaner extraction
• Visible translation progress
• Fewer runtime surprises
• Better scalability

Treat catalogs as Xcode-owned artifacts.
Use .xcloc as the automation boundary.
Keep Git disciplined.

If you build automation around .xcstrings, build it parser-aware and Git-safe — not as blind JSON mutation.

Want to automate your localization workflow?

Our String Catalog Editor lets you upload .xcstrings files and manage translations through a web interface. Start with one free language — no credit card required.