@gernot Only automatically managed strings can get their comment generated, and Xcode generates one as soon as it detects them in code and syncs them into the String Catalog.

The idea is that you are in full control over manual strings (the ones you add to the catalog yourself).
Because you already know how the new string is supposed to be used, you also know what comment is relevant for it.
In order to generate a comment, the string has to be used in code first. That means quite a bit of jumping back & forth to tell Xcode to generate a comment via the context menu.

But yes, please file a feedback if you think it would be beneficial to get a generated comment!

@fruitcoder That is currently not possible, no.
The ideal workflow is one where strings are defined and used in the same module, sharing them across bundles complicates everything.

Changing a key’s spelling, fixing a typo, or adding a format specifier in the String Catalog would break the API of your module if the symbols were public. We didn’t want to introduce that footgun.
Code has deprecation and availability annotations to help with breaking changes, but strings don’t have that.

If you want to keep that project setup consider wrapping your internal symbols in public API. This way it’s obvious that any changes cause clients to break.
It’s more manual work, but because these are obvious changes to public functions, it should make you think about clients.

@kristoffer that is true. Depending on your project structure you might not get the full benefit.

If the symbols were public, fixing a typo in a key or adding a format specifier would break the module’s API and all clients using that symbol though.
In code we have tools like deprecation and availability annotations, which we don’t have for strings.
If you want to keep your current architecture, you could wrap the internal symbols in a public API. This way you stay in full control over what it exposes as API. Yes, that is more manual work, but makes any breaking change really obvious.

@MuseumShuffle @averyvine @BenRiceM @harshil I’m really happy the feature and session are received that well! ☺️

And it was nice meeting you!

@klemensstrasser wow, congratulations 🥳

Some really exciting new APIs in CloudKit Sharing out of #WWDC25!!!

🔗 One Time URL to invite participants without knowing their email address / phone number / userRecordID

👤 Participant Role type of Administrator

📩 CKShareRequestAccessOperation to allow users to request access to a share

🔒 CKRecordZoneEncryptionScope allowing for zone-wide encryption

https://developer.apple.com/documentation/cloudkit/

@gernot That makes me really happy to hear! ☺️

@ryanbooker wait I’m confused now.

Manual strings can be referenced via their key as string in code, or by using the new generated Swift symbol.

Automatic strings usually make their way into the string catalog via extraction from code. They can also be “referenced” via their key, as string in code (so technically a separate string, extracted, and then merged to the other extracted copy).

So when you start with a manually managed string and refactor to use symbols, it stays manually managed.
If you refactor an automatically managed string to be referenced via symbol, it becomes manually managed.

@ryanbooker no, either strings are extracted in code and kept in sync (“automatically managed” incl. comment generation), or you add them in the String Catalog (“manually managed”) and you can change key, value, remove them, and use their generated symbols.

@ryanbooker Thank you!

Find & replace is probably the best option, sorry.
Maybe if you remove the accessors generated by XCStringsTool, and let the compiler warnings guide you to where you use a generated symbol by Xcode? Then you go through them and insert the new symbol names, which should be straight forward thanks to auto completion.

Xcode 26 can help you write helpful comments for extracted strings. This will help translators with context.
Additionally, loading localized strings from a String Catalog is now as easy as calling a function in Swift: Button(.orderButtonTitle)
Auto completion suggests your table name and all manual strings contained in this table!

If you localize your app, I recommend checking out our talk!
I speak about getting started with localization, but then quickly advance into our two big features this year:
Generated comments, and Swift symbols for manually added strings.

https://developer.apple.com/videos/play/wwdc2025/225

Now is the time to book lab appointments for Xcode and localization!

Come and talk with us about your localization workflow.
There’s a good chance that we find one or two opportunities for improvements :)

@Jeehut haha, let me know how you like it 😄

There are some nifty new APIs that didn’t make the keynotes. AlarmKit seems really handy for a wide class of apps. https://developer.apple.com/videos/play/wwdc2025/230

So delighted to share Jeremy and my talk all about rich text editing in SwiftUI with AttributedString! Many people worked together to make this API and this talk happen, and I’m so grateful to all of them! Can’t wait to see it out there in your apps!

RE: https://sfba.social/@jmschonfeld/114655484176931319

If you’re excited about new rich text capabilities in #SwiftUI and powerful AttributedString enhancements, be sure to check out our #WWDC25 session where Max and I dive into all of the details! 🥐🥐 https://developer.apple.com/videos/play/wwdc2025/280

With all the excitement today, don't forget to take advantage and sign up for labs! https://developer.apple.com/wwdc25/sessions-and-labs/one-on-one-labs

Also new this year are some online group labs: https://developer.apple.com/wwdc25/sessions-and-labs/group-labs

#WWDC25

@Typ0genius thank you! And just one of the two big features this year! 🥳

@gernot Sommer too! IL looks pretty good nowadays!