String Catalogs (.xcstrings) solve many localization problems.

But once your app grows, a new issue appears:

the catalog itself becomes too large to manage.

Teams quickly run into:

• thousands of keys in a single file
• hard-to-navigate structures
• merge conflicts in Git
• unclear ownership between features

Scaling localization requires structure.

Why One Giant Catalog Fails

By default, many projects use a single file:

Localizable.xcstrings

This works early on, but breaks down when:

• multiple teams edit strings
• features evolve independently
• translations change frequently

Large catalogs slow down both development and review.

The Better Approach: Multiple Catalogs

Modern iOS localization supports splitting catalogs by feature.

Example structure:

Auth.xcstrings
Onboarding.xcstrings
Settings.xcstrings
Checkout.xcstrings

Each file becomes:

• easier to manage
• easier to review
• less prone to merge conflicts

This mirrors how code is already structured.

Each catalog is only used when explicitly referenced by its table name in code.

How Namespacing Works in Practice

Each catalog is selected via its table name, while key naming provides your logical namespace.

Instead of generic keys:

title
button_label

Use structured keys when needed for clarity:

auth.login.title
checkout.total.label
settings.logout.button

However, in modern String Catalog workflows, you often do not need explicit keys. The base string itself can act as the identifier.

Loading Strings from Specific Catalogs

When using multiple catalogs, you must reference them correctly.

SwiftUI example:

Text("Log In", tableName: "Auth")

This looks up the string in a catalog named Auth.xcstrings.

Important: Xcode only routes strings to that catalog if it exists.

To make this work:

1. Create a new file → String Catalog
2. Name it Auth
3. Build or run your app

Xcode will automatically populate Auth.xcstrings with any strings that use tableName: "Auth".

If the catalog does not exist, the string will not be added to a separate file.

If you are using a variable instead of a string literal:

Text(LocalizedStringKey(label), tableName: "Auth")

Foundation example:

String(localized: "Log In", table: "Auth")

Migration Strategy

If you currently use a single catalog:

1. identify feature boundaries
2. split strings into new catalogs
3. update references in code
4. verify translations

If you are still on legacy formats:

Migrate to String Catalog

Benefits of Splitting Catalogs

Faster development

Smaller files are easier to work with.

Cleaner pull requests

Changes are scoped to specific features.

Better ownership

Teams can manage their own localization.

Reduced merge conflicts

Parallel work becomes safer.

Cross-Platform Alignment

If you support Android, this structure maps naturally.

iOS:

Auth.xcstrings

Android:

res/values/strings_auth.xml

Keeping the same logical grouping across platforms ensures:

• consistent translations
• easier automation
• simpler tooling

Handling Translation Workflows

Splitting catalogs improves translation workflows too.

Instead of exporting everything:

• export only the relevant catalog
• assign it to the right team or translator
• review changes in isolation

This reduces noise and speeds up feedback cycles.

Learn more about review workflows:

Collect Translation Feedback

Avoiding Common Pitfalls

Too many catalogs

Over-splitting creates complexity.

Aim for feature-level grouping, not micro-files.

Inconsistent naming

Stick to predictable naming conventions.

Missing context

Even with smaller files, translators still need clarity.

Add proper comments:

Accurate Translation Comments

When to Split Catalogs

You should consider splitting when:

• your catalog exceeds a few hundred keys
• multiple teams work on localization
• merge conflicts become frequent
• review cycles slow down

How This Fits Into a Scalable Localization System

Structured catalogs are the foundation for:

• Git-based localization workflows
• continuous localization pipelines
• automated translation updates

They make localization predictable and maintainable as your app grows.

Key Takeaways

• large .xcstrings files don’t scale well
• splitting catalogs improves clarity and collaboration
• table names select catalogs, while base strings or keys identify entries
• structure should mirror your app architecture
• cross-platform consistency simplifies workflows

Related Articles

• Xcode Localization Guide
• Migrate to String Catalog
• Accurate Translation Comments
• Protected Terms Glossary