Localizing your apps in Xcode

If you want to localize your iOS, tvOS, WatchOS or OS X apps, there are a few ways for you to do so, which will be explained shortly in this post.

Method A : Base localization

Base localization makes use of your storyboard or xib files.

In short: you can configure an existing view to use other languages. This is essentially handy when you build your app using the Interface Builder.

(For information on how to do this, see this handy tutorial on Appcoda.)

There are however some pitfalls to this method:

  • When you change something in your original Storyboard or xib, the localization files aren't automatically updated as well 🤔.

  • It is cumbersome to change the base localization from within the app, without restarting it. There is no 'official' way to do this, but it should be possible by using the iOS Language Manager library.

Method B : Localization in code

In code, you can localize string easily by placing them in a file called Localizable.strings, and using the NSLocalizedString() function.

Some developers don't use the interface builder at all. For them, this is the only option.

However, for developers who do use the interface builder, this is also an option.

The pitfalls of using interface builder, and in-code localization (assumed you have set the base text in interface builder):

  • You'll somehow need to set all the elements that have localized text in them. This could be done by using IBOutlets, or by finding them by tag. Either way, this is usually not what you want. It makes for lots of boilerplate code, and will mess up your view controllers.

  • Sometimes the text can be set by Interface Builder, while sometimes it will be set in code. This is inconsistent, and extending behavior could be cumbersome.

Conclusion

There is no golden path here. You should determine which one of the methods suits you best. All of them have their set of advantages and downsides.

However, here is some advice:

If you create your views entirely in code.
Use NSLocalizedString in combination with Localized.strings file. Basically, you're golden, since you have no choice. 👍🏼

If you use Interface Builder, and the language needs to be changeable from within the app.
This is a tricky one. Check if you can get the base localization to change with iOS Language Manager . If so, convert your storyboard strings to other languages.
If not, you should use NSLocalizedString in combination with Localized.strings file, and set the views manually from within your ViewController.

If you work sprint-based (like agile) and use Interface Builder.
You're most likely fine using Base localization. You can use ibtool or BartyCrouch to help you keep your files up to date.

About this post
I've written this post as a result of a school assignment. The assignment included an iOS app with localization.

Enthusiastically I started using Base localization and made the app bilingual. Then it struck me; the user had to be able to choose between languages. 😵

This needed demystifying.

Even though Apple seems to encourage the use of Interface Builder, localization options are limited. As a Interface Builder enthusiast, I hope the functionality will soon be extended.

For now I can't fully rely on Interface Builder, since stuff like UIAlertController still needs to be set in code. This makes for a mix of Base localization and localization in code. I'd rather have it centralized.