How to manage iOS translation files (.strings, .xcstrings, .xliff)

Localizing your iOS app is essential if you want to reach users worldwide. But Apple gives you multiple translation file formats: .strings, .stringsdict, .xcstrings, .xcloc, and .xliff, and it's not always clear which one you should use, when, or how they work together.

In this guide, we will walk through each of the iOS localization formats, explain their differences, show examples, and share best practices. You will also learn how to manage them all in SimpleLocalize to simplify your workflow and keep translations consistent.

Why file format choice matters

iOS supports several file formats for localization, each designed for specific scenarios. The choice of file format can impact the ease of translation, the ability to handle complex linguistic features, and the overall efficiency of your localization workflow.

Choosing the right file format isn't just a technical detail:

• Some formats support pluralization and device-specific variants, others don't.
• Some formats carry metadata, comments, and translation states, which help translators.
• Some are better for working with agencies or translation tools.
• Apple is actively evolving which formats it recommends.
• SimpleLocalize supports import, export, CLI, API for all major iOS localization formats, which enables automating sync with your builds.

Does Apple impose a specific format?

Apple doesn’t force you to use a single format, but there are defaults that depend on your tools and iOS version:

Historically (.strings + .stringsdict):

• .strings files were the standard. If you localized a project in older Xcode versions, Apple generated Localizable.strings by default.
• Pluralization was handled separately via .stringsdict files.

Today (.xcstrings):

• Since Xcode 15, the default when you add a new localized string in the String Catalog editor is .xcstrings.
• This format combines .strings and .stringsdict into a single structured file, with added support for metadata and translation state.

Exchange formats (.xcloc & .xliff):

• .xcloc and .xliff are not default storage formats in your repo, they are used when exporting/importing translations for collaboration with agencies

In practice, Apple will load translations from any of these supported formats as long as the files are placed in the correct *.lproj language folder inside your app bundle.

• If your project contains only .strings, iOS will load them.
• If it contains .xcstrings, iOS will load those.
• You can use both formats side by side, which makes gradual migration possible.

Apple is clearly nudging developers toward string catalogs (.xcstrings), but older formats remain supported.

Comparison of iOS translation formats

Here's a summary of the main formats you'll see, what they support, and when to use them. Later sections deepen those details.

.strings: The classic format

.strings files are simple key-value pairs:

// English
"welcome_message" = "Welcome to the app!";
"logout" = "Log out";
"items_count" = "You have %d items.";

// French
"welcome_message" = "Bienvenue dans l'application !";
"logout" = "Se déconnecter";
"items_count" = "Vous avez %d éléments.";

About:

• Plain text key-value pairs, e.g. "key" = "Translated text";
• Stored inside *.lproj folders (e.g., en.lproj/Localizable.strings).
• Classic format for static strings in iOS / macOS.

Limitations:

• No pluralization.
• No metadata or context for translators.
• No built-in device variants.

Use .strings if you are maintaining a legacy app or just need quick, simple localization.

SimpleLocalize support:

You can manage .strings files directly in SimpleLocalize:

simplelocalize upload --apiKey <PROJECT_KEY> \
  --uploadFormat localizable-strings \
  --uploadPath ./{lang}/Localizable.strings

  simplelocalize download --apiKey <PROJECT_KEY> \
  --downloadFormat localizable-strings \
  --downloadPath ./{lang}/Localizable.strings

• Import/export .strings files straight from the translation editor.
• Automate sync with the CLI, REST API, or set up a GitHub integration to keep translations in step with your repository.

Check out our docs for more details regarding .strings support in SimpleLocalize.

.stringsdict: Handling plurals and variants

.stringsdict files are XML-based and support pluralization and device-specific variants:

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
    <key>items_count</key>
    <dict>
    <!-- Pluralization example -->
        <key>NSStringLocalizedFormatKey</key>
        <string>%#@items@</string>
        <key>items</key>
        <dict>
            <key>NSStringFormatSpecTypeKey</key>
            <string>NSStringPluralRuleType</string>
            <key>NSStringFormatValueTypeKey</key>
            <string>d</string>
            <key>one</key>
            <string>You have %d item.</string>
            <key>other</key>
            <string>You have %d items.</string>
        </dict>
    </dict>
    <!-- Device specific example -->
    <key>user_instructions</key>
    <dict>
        <key>NSStringDeviceSpecificRuleType</key>
        <dict>
            <key>iphone</key>
            <string>Tap here</string>
            <key>mac</key>
            <string>Click here</string>
            <key>appletv</key>
            <string>Press here</string>
        </dict>
    </dict>
</dict>
</plist>

About:

• XML format that supports pluralization rules and device-specific variants.
• Must be paired with a .strings file for non-plural text.

Usage:

• For strings that vary depending on count (plural forms).
• For device-specific versions (e.g. different wording or instructions on Mac vs iPhone).

SimpleLocalize support:

You can manage .stringsdict files directly in SimpleLocalize:

simplelocalize upload --apiKey <PROJECT_KEY> \
  --uploadFormat localizable-strings-dict \
  --uploadPath ./{lang}/Localizable.stringsdict

• Import/Export: Fully supported. Upload .stringsdict files directly from the translation editor or via CLI/API.
• In the translation editor, plural forms will be shown as separate translation keys (e.g. items_count.one, items_count.other).

Check out our docs for more details regarding .stringsdict support in SimpleLocalize.

.xcstrings: The modern string catalog

.xcstrings files are JSON-like and combine the features of .strings and .stringsdict, with added metadata:

{
  "version": "1.0",
  "sourceLanguage" : "en",
  "strings" : {
    "hello_world" : {
      "shouldTranslate": true,
      "comment" : "Here is a comment for the translator",
      "extractionState" : "manual",
      "localizations" : {
        "en" : {
          "stringUnit" : {
            "state" : "translated",
            "value" : "Hello World"
          }
        },
        "fr" : {
          "stringUnit" : {
            "state" : "translated",
            "value" : "Bonjour le monde"
          }
        }
      }
    },
    "items_count" : {
      "shouldTranslate": true,
      "comment" : "Number of items in the cart",
      "extractionState" : "manual",
      "localizations" : {
        "en" : {
          "stringUnit" : {
            "state" : "translated",
            "value" : "You have %d items.",
            "pluralForms": {
              "one": "You have %d item.",
              "other": "You have %d items."
            }
          }
        }
      }
    }
  }
}

About:

• Apple’s recommended format starting with Xcode 15.
• JSON-like structure that replaces .strings + .stringsdict.
• Supports pluralization, device variants, comments, and translation state.

Why use it:

• Modern, structured, future-proof.
• Easier to manage in Xcode's GUI.
• Built-in support for plural forms and device variants.

SimpleLocalize support:

String catalogs are fully supported:

simplelocalize upload --apiKey <PROJECT_KEY> \
  --uploadFormat localizable-xcstrings \
  --uploadPath ./Localizable.xcstrings

• Import and export just one .xcstrings file per language or multiple files (namespaces).
• Manage all translations centrally in the translation editor, add new languages, and run auto-translation and quality checks.
• Use CLI, API, or GitHub integration for continuous localization.

Check out our docs for more details regarding .xcstrings support in SimpleLocalize.

.xcloc: Localization catalogs

.xcloc files are packages that contain .xliff localization files along with metadata about the localization project.

MyApp.xcloc/
  ├── Contents.json
  └── Localizations/
        ├── en.xliff
        ├── fr.xliff
        └── de.xliff

About:

• A folder (bundle) containing .xliff files and a Contents.json metadata file.
• Generated by Xcode when you use Export for Localization.

Use case:

• Full localization handoff to translators.
• Best when working with external agencies or teams that use .xliff.

Learn how to upload and download .xcloc files in SimpleLocalize.

.xliff: The exchange format

.xliff (XML Localization Interchange File Format) is a standard XML-based format for exchanging localization data between different tools.

<?xml version="1.0" encoding="UTF-8"?>
<xliff version="1.2">
  <file source-language="en" target-language="fr" datatype="plaintext" original="Localizable.strings">
    <body>
      <trans-unit id="hello_world">
        <source>Hello World</source>
        <target>Bonjour le monde</target>
        <note>Here is a comment for the translator</note>
      </trans-unit>
      <trans-unit id="items_count">
        <source>You have %d items.</source>
        <target>Vous avez %d articles.</target>
      </trans-unit>
    </body>
  </file>
</xliff>

About:

• Industry-standard XML format for exchanging translations.
• Widely supported outside Apple’s ecosystem.
• Can represent complex structures, including plural forms and context.

Use .xliff if you need to collaborate with translation agencies or tools that don’t use Xcode.

SimpleLocalize support:

You can import and export .xliff files directly in SimpleLocalize, from the translation editor or via CLI/API.

simplelocalize upload \
  --apiKey PROJECT_API_KEY \
  --uploadLanguageKey en \
  --uploadFormat xliff:1.2 \
  --uploadPath ./en.xliff

Check out the details in our docs regarding .xliff support in SimpleLocalize.

Managing iOS translations with SimpleLocalize

Manually handling multiple iOS localization formats and translation updates can lead to errors, inconsistencies, and wasted time. SimpleLocalize TMS makes the translation management easier by allowing you to:

• Import/export of all iOS formats via CLI, REST API, or GitHub integration.
• Centralize all your iOS translation files in one place.
• Provide translators with context, comments, and plural forms.
• Collaborate with teams and agencies.
• Auto-translate and run quality checks.
• Automate review process and translation workflows.
• Keep translations in sync with your codebase.

Check some examples of AI-powered localization workflow automation with SimpleLocalize.

Best practices for iOS localization

While iOS provides flexibility in localization formats, following best practices can help to improve your workflow and ensure high-quality translations:

• Use keys, not hardcoded strings. Make them consistent and descriptive.
• Prefer .xcstrings for new projects.
• For large projects, consider namespacing your strings into multiple files.
• Store pluralization in .stringsdict or .xcstrings.
• Provide context and comments for translators.
• Regularly review translations and run quality checks.
• Export .xcloc or .xliff when working with agencies.
• Automate with SimpleLocalize to avoid manual mistakes.

If you are using .strings, keep one Localizable.strings per language. For new projects, prefer .xcstrings catalogs, one per language.

Final thoughts

Apple’s localization formats have evolved from .strings to .xcstrings, with .xcloc and .xliff for translation exchange. While multiple formats are supported, Apple is clearly moving toward string catalogs as the future of iOS localization.

With SimpleLocalize, you don’t have to worry about file quirks. Upload any format, manage translations in one place, and sync them back to your app with a single command.

Ready to simplify your iOS localization workflow? Start with SimpleLocalize.

FAQ

Is Localizable.strings and .strings the same thing?

Yes, Localizable.strings is just a common filename convention for .strings files. You can name your .strings files anything, but Localizable.strings is the default name Xcode uses when you add localization.

Can I mix .strings and .xcstrings in the same app?

Yes. iOS will load translations from both as long as the files are placed in the correct *.lproj folders. This allows you to migrate gradually instead of all at once.

Do I still need .stringsdict if I use .xcstrings?

No, .xcstrings supports pluralization and device variants natively, so you can consolidate everything into a single file per language.

How do I choose between .xcloc and .xliff?

Use .xcloc when exporting/importing full localization projects from Xcode, especially when working with agencies. Use .xliff if you need a more universal format that works across different tools.

Can SimpleLocalize automatically sync translations with my repository?

Yes. Besides manual import/export, you can:

• Use the CLI for batch upload/download.
• Call the REST API for automation.
• Set up the GitHub integration for continuous localization: every commit can trigger a sync of translations.

What if I only need to translate a few strings?

That’s fine. You can import just one .strings or .xcstrings file into SimpleLocalize, add a new language, run auto-translation, and export it back without touching your whole project.

Will Apple remove support for .strings files?

Not in the near future. .strings files are still widely used and supported. However, Apple is clearly moving toward .xcstrings catalogs as the long-term format, so it’s a good idea to adopt them for new projects.