A framework that generates enum
from xcstrings
- Swift enumerations from String Catalog for iOS / iPadOS / macOS / tvOS.
If you are not familiar with Apple's String Catalog (introduced from Xcode 15 - WWDC 23), please check Apple's workflow first.
- Add a
String Catalog
to your project. - Build your app to compile your
String Catalog
from your current codebase. - If you are dealing with an old codebase and needs to provide localization right now, add copies in the String Catalog. Otherwise leave them along. We'll revisit it later.
- Whenever you want to add a new string to the project, always manually create an entry in
Localizable.xcstrings
and add localized string(s).- Use a variable name friendly string as
Key
. - TODO: plural forms etc. is to be added later.
- Use a variable name friendly string as
- Create
enum
in your code that contains all the String Catalog keys.- It can be constructed manually, all you need is to use a
LocalizedStringKey
inSwiftUI.View
, not the String itself.- Helper function:
var key: LocalizedStringKey { LocalizedStringKey(rawValue) }
- Helper function:
- OR use the StringCatalogEnum CLI tool in this repo.
- Download from releases, and copy
xcstrings-enum-generate
to your project. - OR build from source:
cd StringCatalogEnum && make release
- Added something like
xcstrings-enum-generate --xcstrings-path ../Resources/Localizable.xcstrings --output-filename ../Generated/XcodeString.swift
to generate theenum
.
- Download from releases, and copy
- OR use SwiftGen - hopefully better support will be added in future.
- OR explore how to achieve it with Sourcery.
- It can be constructed manually, all you need is to use a
- Use
LocalizedStringKey(key)
in your SwiftUI components.- With
StringCatalogEnum
:Text(XCS.welcomeBack.key)
- With
- At this point, you end up with a native
enum
, hopefully generated from yourString Catalog
.- With
StringCatalogEnum
: remove hard-coded strings from yourSwiftUI
components and create manual keys and localized strings.
- With
This section provides context and high order thinking, which can be ignored by senior developers.
Apple's bare minimum localization implementation is to reuse the mechanisms based on Localizable Strings, and makes it easier to use. Typical workflow is like:
- Write codes like
SwiftUI.Text("Product Title")
. - Add a
String Catalog
to enable localization. - Whenever you build your project, your String Catalog will be automatically updated with new strings.
- What happens is that functions like
Text.init
takeLocalizedStringKey
as a parameter, and they are built into String Catalog, using the same string as both key and (default English) value. - For the reason above,
static let title = "Welcome"
will NOT be built into string catalog automatically.
- What happens is that functions like
- You can add a new language in your String Catalog to achieve localization.
- Replaced the old
INI
style text file with more a modemJSON
based format. - Added a dedicated GUI editor.
- Existing or newly added
SwiftUI
strings can be compiled toxcstrings
file automatically. - Introduced classes like
LocalizedStringKey
,String.LocalizationValue
to support all these localization features.
Or I should say why it's only good to build a MVP app. As long as you have built an app with decent level of complexity, you should have encountered use cases like:
- Short strings like "Share" may be translated to something like "分享" (share) or "点此分享" (tap here to share) in a different language, to fit length of different UI elements.
- A long, 300 characters "lorem ipsum" strings with line breaks looks ugly to fit in your
SwiftUI.View
. - And in general, compile-time check is always good to ensure good code quality, and allows fewer defects in QA stage.
Apple usually doesn't promote certain design patterns. Most of the time, Apple only offers the essential components for you to build your system. This could lead to some bad results, for example, most of experienced iOS developers perhaps have seen massive view controllers more or less. Another example is that Google built components like LiveData
, Room
etc. and promoted their own MVVM
pattern. Apple rarely does that.
I think this is because Apple, at its core, is a company that sells products. It offers tools to build apps for its products, but in the end, implementation is not what Apple is passionate about. Apple probably cares about backward compatibility more, as it does impact the products. So you don't see Apple is promoting using enum
over hard-coded strings in their examples, and it doesn't mean you shouldn't do it yourself.
Companies like Google, on the other hand, are built around technology. They don't hesitate to kill their services and update their tech stack, which sometimes results confusion and frustration. But they do offer more software architectural level of thinking, which can be insightful for developers in their ecosystems.
Of course, this is just a high level summary. Apple built async/wait APIs to promote better codes, and Google still uses XML (bah) for string resources. And just like iOS and Android, we are seeing both parties learn from each other. Hopefully technology will keep evolving.
- CLI tool built from SwiftCLITemplate.