How should I bridge LocalizedStringResource and LocalizedStringKey for custom SwiftUI views?

When building multilingual apps, you want to use the best tool for the job—Apple now recommends representing your localizable strings as LocalizedStringResource so you can supply things like comments, table names, and default values. However, many SwiftUI components (for example, Button and its modifiers like .help(_)) still expect text that conforms to StringProtocol (or a LocalizedStringKey) rather than a LocalizedStringResource. That’s why you see errors when passing a LocalizedStringResource directly.

Conversion Is Currently Required

At this time there isn’t an automatic bridging from LocalizedStringResource to LocalizedStringKey. Until SwiftUI’s APIs are updated to accept LocalizedStringResource directly, you need to convert it explicitly. Using the String(localized:) initializer is the recommended approach:

SWIFTCopied
Button(String(localized: title)) { }
    .help(String(localized: title))

This conversion tells the system to retrieve the localized version of the key stored in the LocalizedStringResource. While it adds a bit of extra code, it preserves the additional metadata you’ve provided (such as comments) that wouldn’t be captured by using a plain string literal.

When to Use Each Type

• LocalizedStringResource
  Use this when you need enhanced localization support. It lets you attach comments and even separate tables, which is helpful when your app’s string catalog grows large. It also expresses developer intent more clearly in code—you’re dealing with a value intended for localization.

• LocalizedStringKey
  SwiftUI automatically treats string literals as LocalizedStringKey values. For many SwiftUI initializers (like Text and Label) this works seamlessly with automatic localization. However, LocalizedStringKey is less flexible; it does not allow you to attach additional metadata like comments or override default values as easily as LocalizedStringResource.

Summary of Trade-Offs

• Using LocalizedStringResource gives you richer localization metadata and a clear intention in your code.
• But currently, many SwiftUI APIs still require conversion to a String (or use LocalizedStringKey) when you’re passing these values into components like Button or modifiers like .help.

Until SwiftUI’s API fully embraces LocalizedStringResource, performing the manual conversion with String(localized:) is the proper approach. It ensures your additional localization context is retained, even though it adds a little extra code.

In short, continue using LocalizedStringResource to represent your localizable strings where you can, and then convert them when needed for SwiftUI views that require StringProtocol types.