@Jeehut Thanks for sharing this useful link.

I‘m using multiple Localizable.strings tables and it is pretty convinient now to access them via seperate enums e.g. L10n, L20n. What is the migration path in this case? Exchange the enums via search and replace to string keys is s lot of work to do, especially with multiple tables.

I have some tables where I access the localized strings programmatically. So here I would loose the source of truth since the source is in the table and not in the code. Is there any workaround for this issue or can I disable the stalled string warnings?

You can even use your code as the source of truth when doing things outside of SwiftUI programmatically. Just use String(localized: "Your Key"). Parameters are also supported.

But in general, regarding migrating from SwiftGen calls to String Catalogs: Because the source-of-truth changes from the .strings files to the source code, the old and the new style are so different that I don't think there's an easy way to migrate. One could write a tool that replaces each call into L10n etc with something like String(localized:) with the key, but that's not something I'm interested in.

I personally do it like this: For any project where I already have .strings files and BartyCrouch / RemafoX in place, I just keep things as they are since Apple isn't even planning on removing .strings files. Quite the opposite, the .xcstrings file is a layer on top of .strings and during build-time it is converted to .strings files, so we just get a "higher-level" abstraction. But we can still keep the lower layer, so if you have many L10n calls and different sources for them, it's probably wise to keep it like this for the time being. Even with "best practices" in mind, I don't see any downside as String Catalogs just "catch up" with what BartyCrouch + SwiftGen already offers. You won't "win" anything if you migrate.

But for new project or maybe even new feature modules, you might want to opt for String Catalogs. I'm not aware of another method to put them into separate files than separating features into Swift packages, which seem to support catalogs as well (haven't tested).