Implement, review, or improve localization and internationalization in iOS/macOS apps — String Catalogs (.xcstrings), generated localizable symbols, stable key naming, LocalizedStringKey, LocalizedStringResource, pluralization, FormatStyle for numbers/dates/measurements, right-to-left layout, Dynamic Type, and locale-aware formatting. Use when adding multi-language support, setting up String Catalogs, enabling generated symbols for compile-time-safe localization keys, handling plural forms, formatting dates/numbers/currencies for different locales, testing localizations, or making UI work correctly in RTL languages like Arabic and Hebrew.
SKILL.md
iOS Localization & Internationalization
Localize Apple-platform apps with String Catalogs, modern string types,
locale-aware formatting, and right-to-left layout.
String Catalogs are the recommended Xcode 15+ workflow for new localization work. They keep localizable strings, pluralization rules, and device variations together in an Xcode-managed JSON file with a visual editor. Legacy .strings and .stringsdict files can coexist during migration, but new Swift and SwiftUI code should default to String Catalogs.
Generated symbols are an Xcode 26 typed-access layer on top of String Catalogs;
they do not change the catalog's Xcode 15 availability.
Enable: Build Settings > Localization > Generate String Catalog Symbols → Yes (on by default in new Xcode 26 projects). Requires catalog format version 1.1.
Workflow: Add a key manually via the (+) button in the String Catalog editor — manual keys have the Generate Swift Symbol checkbox enabled by default. Auto-extracted keys can also opt in via Refactor > Convert Strings to Symbols. Use stable manual keys for generated-symbol strings. Avoid source-copy-derived keys for API-facing strings because wording edits can rename generated identifiers and churn call sites.
// Generated from key "room_available" in Localizable.xcstrings
Text(.roomAvailable)
// Parameterized key "landmarks_count" with %1$(count)lld
Text(.landmarksCount(count: 42))
// Non-default table "Booking.xcstrings"
Text(.Booking.confirmBookingCta)
Xcode derives symbol names by camelCasing the key: settings.notifications.toggle → .settingsNotificationsToggle. You can convert existing extracted strings to symbols via Refactor > Convert Strings to Symbols (reversible).
Generated symbols are internal. For cross-module access, create a public wrapper extension. For heavier multi-module setups, use xcstrings-tool instead.
For the full generated symbols reference — extraction states, symbol derivation rules, and cross-module patterns — see references/string-catalogs.md.
String Types -- Decision Guide
Context
Type
Why
SwiftUI view text
LocalizedStringKey (implicit)
SwiftUI performs lookup
View models, services, and errors
String(localized:)
Resolves to String now
App Intents, widgets, deferred system UI
LocalizedStringResource
Carries localization until display
Non-user-facing logs and analytics
Plain String
No localization needed
LocalizedStringKey (SwiftUI default)
SwiftUI views accept LocalizedStringKey for their text parameters. String literals are implicitly converted -- no extra work needed.
Use LocalizedStringKey when passing strings directly to SwiftUI view initializers. Do not construct LocalizedStringKey manually in most cases.
String(localized:) -- Modern NSLocalizedString replacement
Use for any localized string outside a SwiftUI view initializer. Returns a plain String. The literal/interpolated initializer is available iOS 15+; resolving a LocalizedStringResource is iOS 16+.
let title = String(localized: "Welcome back")
let msg = String(localized: "error.network",
defaultValue: "Check your internet connection")
For Swift package localization failures, answer with this explicit resource checklist before bundle debugging:
Package.swift declares defaultLocalization.
The target resources list processes the catalog location, such as .process("Resources").
Localizable.xcstrings is actually inside that processed target-resource path.
Only after those pass, debug lookup with bundle: .module or Text(..., bundle: .module).
Existing NSLocalizedString literal keys can still be exported or migrated by Xcode tooling, but new Swift code should prefer String(localized:), SwiftUI literals, LocalizedStringResource, or generated symbols.
LocalizedStringResource -- Pass localization info without resolving
Use when a string must be carried as a localizable value for later resolution, especially for App Intents, widgets, notifications, generated localizable symbols, and system APIs that accept LocalizedStringResource directly. Use String(localized:) when code needs the resolved string immediately. Available iOS 16+.
Interpolated values in localized strings become positional arguments that translators can reorder.
// English: "Welcome, Alice! You have 3 new messages."
// German: "Willkommen, Alice! Sie haben 3 neue Nachrichten."
// Japanese: "Alice さん、新しいメッセージが 3 件あります。"
let text = String(localized: "Welcome, \(name)! You have \(count) new messages.")
In the String Catalog, this appears with %@ and %lld placeholders that translators can reorder:
English: "Welcome, %@! You have %lld new messages."
Japanese: "%@さん、新しいメッセージが%lld件あります。"
Type-safe interpolation (preferred over format specifiers):
String Catalogs handle pluralization natively -- no .stringsdict XML required.
Setup in String Catalog
When a localized string contains an integer interpolation, Xcode detects it and offers plural variants in the String Catalog editor. Supply translations for each CLDR plural category:
Category
English example
Arabic example
zero
(not used)
0 items
one
1 item
1 item
two
(not used)
2 items (dual)
few
(not used)
3-10 items
many
(not used)
11-99 items
other
2+ items
100+ items
English uses only one and other. Arabic uses all six. Always supply other as the fallback.
String Catalogs support device-specific text (iPhone vs iPad vs Mac):
// In String Catalog editor, enable "Vary by Device" for a key
// iPhone: "Tap to continue"
// iPad: "Tap or click to continue"
// Mac: "Click to continue"
Use Foundation's automatic grammar agreement markup when nearby words must
inflect for a value's number or gender. Preserve the complete inflecting phrase
for translators; see Automatic Grammar Agreement.
FormatStyle -- Locale-Aware Formatting
Never hard-code user-facing formats. Use FormatStyle and test output under
contrasting locales such as en_US, de_DE, ar_SA, and ja_JP.
ios-localization owns FormatStyle guidance when the issue is locale-aware user-facing display, including numbers, dates, currency, units, names, lists, calendars, separators, and locale preview/testing. For custom FormatStyle, ParseableFormatStyle, parsing, Date.IntervalFormatStyle, URL.FormatStyle, or reusable formatter API design, route to swift-formatstyle; keep ios-localization advice to locale risks and testing unless implementation is explicitly requested.
Dates
let now = Date.now
// Preset styles
now.formatted(date: .long, time: .shortened)
// US: "January 15, 2026 at 3:30 PM"
// DE: "15. Januar 2026 um 15:30"
// JP: "2026年1月15日 15:30"
// Component-based
now.formatted(.dateTime.month(.wide).day().year())
// US: "January 15, 2026"
// In SwiftUI
Text(now, format: .dateTime.month().day().year())