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.
String Catalog
to your project.String Catalog
from your current codebase.Localizable.xcstrings
and add localized string(s).
Key
.enum
in your code that contains all the String Catalog keys.
LocalizedStringKey
in SwiftUI.View
, not the String itself.var key: LocalizedStringKey { LocalizedStringKey(rawValue) }
xcstrings-enum-generate
to your project.cd StringCatalogEnum && make release
xcstrings-enum-generate --xcstrings-path ../Resources/Localizable.xcstrings --output-filename ../Generated/XcodeString.swift
to generate the enum
.LocalizedStringKey(key)
in your SwiftUI components.
StringCatalogEnum
: Text(XCS.welcomeBack.key)
enum
, hopefully generated from your String Catalog
.
StringCatalogEnum
: remove hard-coded strings from your SwiftUI
components and create manual keys and localized strings.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:
SwiftUI.Text("Product Title")
.String Catalog
to enable localization.Text.init
take LocalizedStringKey
as a parameter, and they are built into String Catalog, using the same string as both key and (default English) value.static let title = "Welcome"
will NOT be built into string catalog automatically.Localizable String
approachINI
style text file with more a modem JSON
based format.SwiftUI
strings can be compiled to xcstrings
file automatically.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:
SwiftUI.View
.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.