Localization in Swift like a Pro
How to write safer localization code and save time by getting less distracted from your actual code writing task in Xcode.
✨ Update ✨There’s now a new Mac app called ReMafoX which is the successor to BartyCrouch, the tool which is explained in this article. It improves upon several aspects of BartyCrouch and even has a set of video guides that you might want to watch. Get it here for free.
The Status Quo in Xcode
As developers we know for a fact that context switches are inefficient. This does not only apply to CPUs though, it’s also true for the coding process itself. Often times we start writing code we need to immerse ourselves into, that’s why developer tools try to support us with any little task that might distract us from writing the actual code.
Xcode is a very good development environment in that it helps us app developers both with basic development tasks (like code completion, syntax highlighting, refactoring) and more complex tasks like defining device-agnostic UIs (Interface Builder) as well as several kinds of debugging and testing tools (View Hierarchy Debugger, UI / Performance Testing).
Missing Feature #1: Keeping Localizations in Sync
But at some tasks which are clearly not part of the coding process, Xcode lacks convenience. One such example is keeping localizations in sync between:
- Code Files (e.g.
- Storyboards / XIBs and their Strings files
- The different locales of a Strings file
Apple actually does provide tools to update Strings files, namely
ibtool and the
genstrings and its successor
extractLocStrings. You can experience them in field within Xcode when you add a language to an existing Strings file: Xcode will automatically use existing keys in a source language to prefill the new languages Strings file. You will also have noticed that when you first localize a Storyboard or XIB file, Xcode automatically adds all localizable Views (like
UILabel) to the corresponding Strings files. But that's where…