How to Localize an iOS App: Step-by-Step (Xcode String Catalogs + App Store)

Localizing an iOS app used to mean wrestling with .strings files, a separate .stringsdict for plurals, and a lot of copy-paste errors. Not anymore. Since Xcode 15, String Catalogs (.xcstrings) put every translatable string, every language, and every plural rule into one file that Xcode keeps in sync for you automatically. In 2026, with Xcode 26, this is simply how you localize.

Here’s the short version: add a String Catalog, build your project so Xcode extracts your strings, add languages, translate (yourself, with AI, or through a service), handle plurals and variables, test with scheme languages, then localize your App Store metadata. This guide walks through each step with the gotchas we hit doing it on real apps. If you want the strategy-level view first (which markets, what to translate beyond strings), our pillar guide on how to localize iOS and macOS apps covers that side.

Step 1: Create a String Catalog

In Xcode, go to File > New > File, scroll to the Resources section, and pick String Catalog. Keep the default name, Localizable.xcstrings, unless you have a reason not to (some frameworks look for that exact name). Drop it in your main app target.

That’s genuinely it for setup. Under the hood it’s a JSON file, which means it plays nicely with git, and merge conflicts are far less painful than the old format.

Step 2: Let Xcode extract your strings

Here’s the part that feels like magic the first time. Build your project (Cmd+B) and Xcode scans your code for localizable strings and adds them to the catalog as keys. It picks up:

• SwiftUI Text(“Hello”) views (string literals in SwiftUI are localization keys by default)
• String(localized: “welcome_message”) calls in Swift
• NSLocalizedString in older Objective-C or Swift code
• Strings in your storyboards and xibs, if you still have any

One catch: interpolated strings you build with plain concatenation won’t get extracted. Use String(localized:) with format specifiers instead of gluing strings together. So “You have \(count) items” inside a Text view is fine, but manually concatenated sentences are not, and they’ll also break grammar in languages with different word order.

Step 3: Add your target languages

Open the .xcstrings file, click the + button at the bottom of the language sidebar, and pick a language. Each one shows a translation progress percentage, which is surprisingly motivating when you’re grinding through 300 strings.

Which languages first? Look at your analytics and your keyword data. Spanish, German, French, Japanese, and Portuguese (Brazil) tend to give the best return for most categories. Our guide to ASO keyword research shows how to check search volume per storefront before you commit, because translating into a language nobody searches you in is wasted effort.

Step 4: Translate the strings

You’ve got three realistic options, and honestly most indie devs end up mixing them:

Method	Cost	Quality	Best for
Manual (you or a bilingual friend)	Free-ish	Great if fluent	1-2 languages you actually speak
AI translation (Xcode’s built-in intelligence, ChatGPT, DeepL)	Free to cheap	Good, needs review	First pass across many languages
Professional service (Lokalise, Crowdin, agencies)	Roughly $0.08-0.25 per word	Best	Revenue-critical apps, marketing copy

For AI or service workflows, don’t hand over the raw JSON. Use Editor > Export Localizations in Xcode, which produces an .xcloc bundle per language containing industry-standard XLIFF files plus screenshots for context. Translators (human or machine) do their thing, then you pull it all back in with Editor > Import Localizations. Xcode marks imported strings as “reviewed” so you can track what’s done.

Whatever route you pick, add comments to your strings. In code that’s the comment parameter on String(localized:), and it shows up right in the catalog. “Bank” the building and “bank” the river bank translate very differently, and your translator can’t see your UI.

Step 5: Handle plurals and variables

This is where String Catalogs really earn their keep. The old way needed a separate .stringsdict file with genuinely unpleasant XML. Now: right-click any string in the catalog, choose Vary by Plural, and Xcode generates the plural categories for each language automatically.

And it’s smart about it. English gets “one” and “other”. Russian gets “one”, “few”, “many”, and “other” because that’s how Russian actually works. Arabic gets six categories. You just fill in the boxes, and the right CLDR rules apply at runtime.

There’s also Vary by Device, so “Tap to continue” on iPhone can become “Click to continue” on Mac without any code changes. Handy if you’re shipping Mac Catalyst or a shared SwiftUI codebase.

Step 6: Test without changing your phone’s language

Please don’t set your whole device to German to test. Xcode has better tools:

1. Scheme languages: Edit Scheme > Run > Options > App Language. Pick any language and run. This is the fastest loop.
2. Pseudolanguages: in the same menu, run with “Double-Length Pseudolanguage” to catch layouts that explode when German turns your 8-character button label into 24 characters. There’s also a right-to-left pseudolanguage for Arabic and Hebrew layout testing.
3. SwiftUI Previews: set the locale environment on a preview to check individual screens per language without launching the simulator.

Things to look for: truncated labels, buttons that grow past their container, hardcoded strings you missed (they’ll stay in English), and dates or numbers you formatted by hand instead of using formatters. On my test runs, text expansion is the number one thing that breaks, so give your layouts room to breathe.

Step 7: Localize your App Store listing

Your app speaks five languages, but if the App Store listing is English-only, users in Madrid will never find out. In App Store Connect, open your app’s version page and use the language selector near the top right to add localizations. For each language you can (and should) localize:

• App name and subtitle (30 characters each, and character counting matters in every language)
• The keyword field (100 characters, do fresh keyword research per storefront, don’t just translate your English keywords)
• Description and promotional text
• Screenshots, ideally captured while running the app in that language
• In-app purchase display names and descriptions

The keyword point deserves repeating: Spanish users don’t necessarily search for the literal translation of your English terms. That’s a research job, not a translation job.

Common mistakes to avoid

• Hardcoding user-facing strings outside the catalog. Turn on the “Missing Localizability” build warning in Build Settings to catch them.
• Concatenating sentences from fragments. Word order differs across languages; always use full sentences with format placeholders.
• Forgetting formatters. Dates, currencies, and numbers should go through Foundation’s formatters, which localize for free. 1,000.50 in the US is 1.000,50 in Germany.
• Ignoring right-to-left. If you support Arabic or Hebrew, test with the RTL pseudolanguage; SwiftUI handles most of it, but custom drawing and hardcoded leading/trailing assumptions break.
• Translating strings but not images. Screenshots with English text inside look half-finished to non-English users.
• Shipping without a native speaker review. Even one hour of review per language catches the embarrassing stuff AI translation misses.

Localization is one piece of a bigger release pipeline. If you’re earlier in the journey, start with our complete guide to building iOS and Mac apps, and when you’re planning the rollout, work through our mobile app localization checklist so nothing slips through.

FAQ

Do I need to migrate my old .strings files to String Catalogs?

You don’t have to, but you should. Right-click a .strings or .stringsdict file in Xcode and choose Migrate to String Catalog. It’s a one-way, largely automatic conversion, and you get plural handling and progress tracking for free. Do it on a clean branch and diff the result.

How much does it cost to localize an iOS app?

DIY with AI translation: basically free plus your review time. Professional translation runs roughly $0.08 to $0.25 per word, so a typical app with 2,000 words of UI text lands around $160 to $500 per language, plus App Store metadata.

Does localization actually increase downloads?

In our experience, yes, when you pick markets deliberately. Localized keywords and screenshots can lift conversion noticeably in non-English storefronts because you’re suddenly competing in a much shallower pool. Just don’t expect miracles from a machine-translated listing in a market you never researched.

Can I localize just the App Store page without translating the app?

Technically yes, and some devs do it as a cheap test of demand in a market. But users who download expecting Spanish and get English tend to leave one-star reviews, so treat it as a short-term experiment, not a strategy.