Current String Catalogs "support" is broken for static libraries

Metadata

Source

tuist/tuist #7673

Updated

Jun 11, 2026

Domains

Generated projects

Details

What happened?

When a target is a static library with a String Catalog resource file, this file is bundled with the automatically generated companion bundle. While this ensures that localization works during the runtime, it breaks Xcode’s string extraction.

Here is a potential fix: Add this String Catalog file to the static library’s Copy Bundle Resources list

Even though this file will not be copied into a bundle, since a static library has no bundle, this String Catalog file will still be picked up by Xcode correctly to sync localizable strings. The existing behavior of copying it to a companion bundle is also required, to make sure that the localization can be found during the runtime.

I have read #6048 , which is related but a separate issue. There, @leszko11 ‘s proposal is to generate a strongly typed enum with all available strings. Here, the goal is to get String Catalog’s extraction to work correctly.

How do we reproduce it?

https://github.com/notcome/tuist-xcstring-issue

Above repo contains a minimal example, and includes an ad-hoc script to fix this issue.

Error log

Irrelevant here

macOS version

15.5

Tuist version

4.52.0

Xcode version

16.4

Flights

Investigate, reproduce, or fix this item in an isolated repository. Each Flight preserves its outcome and agent session.

New Flights are paused Configure model inference, GitHub, and a sandbox provider to start another Flight. Existing results remain available below.

No Flights yet

Start a Flight and preserve its objective, outcome, and session here.

Comments

D

dosubot[bot] Jun 12, 2025

Tuist handles resources in static libraries by creating a companion .bundle target, which includes String Catalogs. This setup works for runtime localization, but currently, Tuist does not implement special handling or synthesized accessors for String Catalogs (.xcstrings)—this part is marked as a work-in-progress in the codebase. As a result, Xcode’s string extraction doesn’t work as expected for static libraries, and .xcstrings are just treated as generic resources in the bundle. Your proposed workaround—adding the String Catalog to the static library’s Copy Bundle Resources list—aligns with how Xcode expects to find these files for extraction, and is a reasonable approach given the current state of Tuist’s implementation. There isn’t any official documentation or built-in support for this scenario yet, and no existing tickets or discussions directly address this specific extraction issue. For now, your ad-hoc script is the best available solution until Tuist adds first-class support for String Catalogs in static libraries.
Relevant code references
WIP status for .xcstrings

To reply, just mention @dosu.

Docs are dead. Just use Dosu.

F

fortmarek Jun 12, 2025

Hey @notcome 👋

Yes, this is definitely a need. What would fix this issue is to remove the auto-generated bundle completely for static frameworks as that’s no longer necessary. We had to revert that in https://github.com/tuist/tuist/pull/7232, but it’s definitely something we want to bring back. In that PR, I listed the issues that forced us to revert at the time.

If you’d be up to contribute, we’d be happy to give you the support needed. We might get to it, but we’re not sure, yet, when.