Localization is not “adding strings”.
It is:
- layout adaptation
- plural logic
- dynamic text lengths
- RTL support
- formatting rules
- runtime language switching
Most apps break the moment they leave English.
This post shows how to design localization-safe SwiftUI architecture from day one.
🧠 The Core Principle
Text is data, not decoration.
If your UI assumes English length, it is already broken.
🧱 1. Typed Localization Keys
Never use raw strings:
Text("welcome_title")
Use keys:
enum L10n {
static let welcomeTitle = LocalizedStringKey("welcome_title")
}
Now refactors are safe.
🌍 2. Dynamic Layout First
Avoid fixed widths.
Bad:
.frame(width: 120)
Good:
.frame(maxWidth: .infinity)
Test with:
- German
- Arabic
- Japanese
If it survives German, it’s safe.
🔁 3. Pluralization Support
Use .stringsdict:
<key>items_count</key>
<dict>
<key>NSStringLocalizedFormatKey</key>
<string>%#@items@</string>
</dict>
SwiftUI:
Text("items_count \(count)")
Never build plurals manually.
🧭 4. RTL Readiness
Use:
-
leading/trailing -
HStackinstead of absolute offsets -
layoutDirectionenvironment
Avoid .left / .right.
🧠 5. Locale-Aware Formatting
Text(date, format: .dateTime.month().day())
Never format manually.
🧪 6. Localization Testing
Enable pseudo-languages:
- Double-length
- RTL
Xcode → Scheme → Application Language.
If it breaks, fix now — not after release.
❌ 7. Common Anti-Patterns
Avoid:
- string concatenation
- hardcoded dates
- fixed frames
- embedded grammar
- layout assumptions
🧠 Mental Model
Language
→ Layout
→ Format
→ UI
🚀 Final Thoughts
Localization is architecture.
Do it early, or pay for it forever.
Top comments (0)