Failed to decode target build setting

Hi @Nonouf! I’m Dosu and I’m helping the tuist team.

This error is a known issue in Tuist and is often triggered by Swift Package Manager (SPM) settings in your dependencies or manifest that Tuist doesn’t yet support or decode properly—such as .interoperabilityMode(.Cxx), .defaultIsolation(nil), or certain macro/plugin settings. It can also happen if a dependency only supports certain platforms (like macOS) but is included for all platforms in your manifest, or if your manifest or a dependency’s manifest is malformed or uses a newer SPM feature that Tuist hasn’t mapped yet [8367] [5678].

This decoding failure can even occur in vanilla projects generated by tuist init on recent macOS/Xcode/Swift toolchains, indicating a systemic issue with Tuist’s manifest loading pipeline on newer environments [8387].

What you can try:

• Check your Package.swift and any dependencies for settings like .interoperabilityMode(.Cxx) or .defaultIsolation(nil). If present, try removing or replacing them (e.g., use .linkedLibrary("c++") instead of .interoperabilityMode(.Cxx)) [5678].
• If you use macros or plugins, make sure they’re only included for the platforms they support (e.g., limit to macOS if needed) [8016].
• Run tuist generate --verbose to see if the logs point to a specific file or dependency.
• If you recently updated Xcode, Swift, or macOS, this could be a compatibility issue between Tuist and the latest toolchain. There are no merged fixes for this in the latest Tuist versions yet [8387].

If you can isolate the problematic dependency or setting, removing or downgrading it may unblock you. Otherwise, this appears to be a systemic issue with Tuist’s manifest decoding on the latest platforms, and further investigation from maintainers is ongoing.

To reply, just mention @dosu.

Share context across your team and agents. Try Dosu.

For us the issue was apple.swift-protobuf being updated from 1.33.1 to 1.33.3 We reverted this back in our Package.resolvedand got it back working properly

{
      "identity" : "apple.swift-protobuf",
      "kind" : "registry",
      "location" : "",
      "state" : {
        "version" : "1.33.1"
      }
}

Got a simple project to reproduce the issue, you can find it attached here

test-protobuf-1.33.2.zip

For us the issue was apple.swift-protobuf being updated from 1.33.1 to 1.33.3 We reverted this back in our Package.resolvedand got it back working properly

{ “identity” : “apple.swift-protobuf”, “kind” : “registry”, “location” : “”, “state” : { “version” : “1.33.1” } }

Hey, how did you figured that it had been updated? in your git history?

Hello @dosu, we are facing the exact same issue

Loading and constructing the graph
It might take a while if the cache is empty
✖ Error 
  The data couldn’t be read because it is missing. 
  Sorry this didn’t work. Here’s what to try next: 
   ▸ If the error is actionable, address it
   ▸ If the error is not actionable, let's discuss it in the <Troubleshooting & how to: https://community.tuist.dev/c/troubleshooting-how-to/6>
   ▸ If you are very certain it's a bug, <file an issue: https://github.com/tuist/tuist>
   ▸ Check out the logs at /Users/admin/.local/state/tuist/logs/FA97FD84-2B8F-46A5-8E64-67511EB14F21.log

But we didn’t updated any of our dependencies. Our macminis started to fail yesterday afternoon without understanding why. And by the way, everything is still working locally on our machine. Tell me what information you’d need to help us on this subject?

To help diagnose this, could you provide the following from both your failing macminis and your working local machine: the exact versions of Tuist, Xcode, Swift, and macOS? Please also upload the contents of the log file from a failing run (/Users/admin/.local/state/tuist/logs/FA97FD84-2B8F-46A5-8E64-67511EB14F21.log).

Check if your Package.resolved or other lockfiles differ between environments, and let me know if there were any recent system or toolchain updates on the macminis (even automatic ones). If possible, run tuist generate --verbose on a failing machine and share the output.

This error often appears when there are subtle environment differences or recent changes in the toolchain, even if dependencies haven’t changed. Comparing these details will help pinpoint the cause and the right workaround.

To reply, just mention @dosu.

Docs are dead. Just use Dosu.

Hello @dosu

in our mise.toml file we are pointing tuist to: tuist = ‘4.89.0’

Here is a working version of our terminal locally:

[17:17:10]: ---------------------------
[17:17:10]: --- Step: shell command ---
[17:17:10]: ---------------------------
[17:17:10]: ----------------------------------------
[17:17:10]: --- Step: Verifying fastlane version ---
[17:17:10]: ----------------------------------------
[17:17:10]: Your fastlane version 2.228.0 matches the minimum requirement of 2.116.0  ✅
[17:17:10]: ------------------------------
[17:17:10]: --- Step: default_platform ---
[17:17:10]: ------------------------------
Fastfile:17: warning: already initialized constant Fastlane::FastFile::CHANGELOG_FOLDER_ABSOLUTE_PATH
NotificationsFastfile:3: warning: previous definition of CHANGELOG_FOLDER_ABSOLUTE_PATH was here
[17:17:10]: Driving the lane 'ios ci_unit_tests' 🚀
[17:17:10]: -------------------
[17:17:10]: --- Step: is_ci ---
[17:17:10]: -------------------
[17:17:10]: --------------------------------
[17:17:10]: --- Step: clear_derived_data ---
[17:17:10]: --------------------------------
[17:17:10]: Derived Data path located at: /Users/bertrandbloch/Library/Developer/Xcode/DerivedData
[17:17:11]: Successfully cleared Derived Data ♻️
[17:17:11]: Checking if unit tests report file exists at '/Users/bertrandbloch/Developer/Swift/Xcode15/veepee/.test-reports/unit/testResultBundle.xcresult'
[17:17:11]: Unit tests report file does not exist
[17:17:11]: -----------------------------------------------------------------------
[17:17:11]: --- Step: MISE_LOG_LEVEL=error ~/.local/bin/mise x -- tuist install ---
[17:17:11]: -----------------------------------------------------------------------
[17:17:11]: $ MISE_LOG_LEVEL=error ~/.local/bin/mise x -- tuist install
[17:17:11]: ▸ Resolving and fetching plugins.
[17:17:11]: ▸ Resolving and fetching dependencies.
[17:17:23]: ▸ ✔ Success
[17:17:23]: ▸ Plugins resolved and fetched successfully.
[17:17:23]: ------------------------------------------------------------------------------------------------------------
[17:17:23]: --- Step: swift package resolve --package-path /Users/bertrandbloch/Developer/Swift/Xcode15/veepee/Tuist ---
[17:17:23]: ------------------------------------------------------------------------------------------------------------
[17:17:23]: $ swift package resolve --package-path /Users/bertrandbloch/Developer/Swift/Xcode15/veepee/Tuist
[17:17:33]: ----------------------------------------------------------------------------------------------------------------------------------------------------------
[17:17:33]: --- Step: MISE_LOG_LEVEL=error ~/.local/bin/mise x -- tuist generate -p /Users/bertrandbloch/Developer/Swift/Xcode15/veepee/Projects/Veepee/ --no-open ---
[17:17:33]: ----------------------------------------------------------------------------------------------------------------------------------------------------------
[17:17:33]: $ MISE_LOG_LEVEL=error ~/.local/bin/mise x -- tuist generate -p /Users/bertrandbloch/Developer/Swift/Xcode15/veepee/Projects/Veepee/ --no-open
[17:17:33]: ▸ Loading and constructing the graph
[17:17:33]: ▸ It might take a while if the cache is empty
[17:17:36]: ▸ Using cache binaries for the following targets:
[17:17:36]: ▸ Generating workspace Veepee.xcworkspace
[17:17:36]: ▸ Generating project Ambassador
[17:17:36]: ▸ Generating project metrics
[17:17:36]: ▸ Generating project GoogleDataTransport
[17:17:36]: ▸ Generating project swift-clocks
[17:17:36]: ▸ Generating project GoogleAppMeasurement
[17:17:36]: ▸ Generating project nanopb
[17:17:36]: ▸ Generating project Promises
[17:17:36]: ▸ Generating project Veepee
[17:17:36]: ▸ Generating project swift-navigation
[17:17:36]: ▸ Generating project swift-collections
[17:17:36]: ▸ Generating project Kingfisher
[17:17:36]: ▸ Generating project Alamofire
[17:17:36]: ▸ Generating project KeychainAccess
[17:17:36]: ▸ Generating project combine-schedulers
[17:17:36]: ▸ Generating project swift-custom-dump
[17:17:36]: ▸ Generating project GTMAppAuth
[17:17:36]: ▸ Generating project GoogleSignIn
[17:17:36]: ▸ Generating project RxSwiftExt
[17:17:36]: ▸ Generating project xctest-dynamic-overlay
[17:17:36]: ▸ Generating project GoogleUtilities
[17:17:36]: ▸ Generating project Embassy
[17:17:36]: ▸ Generating project Mixpanel
[17:17:36]: ▸ Generating project RxSwift
[17:17:36]: ▸ Generating project iOSSnapshotTestCase
[17:17:36]: ▸ Generating project GTMSessionFetcher
[17:17:36]: ▸ Generating project Firebase
[17:17:36]: ▸ Generating project Lottie
[17:17:36]: ▸ Generating project swift-dependencies
[17:17:36]: ▸ Generating project swift-perception
[17:17:36]: ▸ Generating project swift-concurrency-extras
[17:17:36]: ▸ Generating project AppAuth
[17:17:36]: ▸ Generating project swift-case-paths
[17:17:36]: ▸ Generating project swift-syntax
[17:17:38]: ▸ Total time taken: 4.537s
[17:17:38]: ▸ ✔ Success
[17:17:38]: ▸ Project generated.
[17:17:38]: ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[17:17:38]: Step: set -o pipefail && TUIST_CONFIG_AUTOMATION_PATH=/Users/bertrandbloch/Developer/Swift/Xcode15/veepee/Projects/Veepee/ MISE_LOG_LEVEL=error ~/.local/bin/mise x -- tuist test -p /Users/bertrandbloch/Developer/Swift/Xcode15/veepee/Projects/Veepee/ -d 'iPhone 17 Pro' -o '26.0' -C veepee-debug --skip-ui-tests -T '/Users/bertrandbloch/Developer/Swift/Xcode15/veepee/.test-reports/unit/testResultBundle.xcresult' --verbose | xcpretty --test --color
[17:17:38]: ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[17:17:38]: $ set -o pipefail && TUIST_CONFIG_AUTOMATION_PATH=/Users/bertrandbloch/Developer/Swift/Xcode15/veepee/Projects/Veepee/ MISE_LOG_LEVEL=error ~/.local/bin/mise x -- tuist test -p /Users/bertrandbloch/Developer/Swift/Xcode15/veepee/Projects/Veepee/ -d 'iPhone 17 Pro' -o '26.0' -C veepee-debug --skip-ui-tests -T '/Users/bertrandbloch/Developer/Swift/Xcode15/veepee/.test-reports/unit/testResultBundle.xcresult' --verbose | xcpretty --test --color

+------------------------------------------------------------------------------------+
|                                  fastlane summary                                  |
+------+---------------------------------------------------------------+-------------+
| Step | Action                                                        | Time (in s) |
+------+---------------------------------------------------------------+-------------+
| 1    | shell command                                                 | 0           |
| 2    | Verifying fastlane version                                    | 0           |
| 3    | default_platform                                              | 0           |
| 4    | is_ci                                                         | 0           |
| 5    | clear_derived_data                                            | 0           |
| 6    | MISE_LOG_LEVEL=error ~/.local/bin/mise x -- tuist install     | 12          |
| 7    | swift package resolve --package-path /Users/bertrandbloch/Dev | 10          |
| 8    | MISE_LOG_LEVEL=error ~/.local/bin/mise x -- tuist generate -p | 4           |
| 9    | set -o pipefail && TUIST_CONFIG_AUTOMATION_PATH=/Users/bertra | 13          |
+------+---------------------------------------------------------------+-------------+

[17:17:51]: fastlane.tools finished successfully 🎉

But on our Mac mini:

[17:39:01]: --------------------------------------------------------------------
[17:39:01]: $ MISE_LOG_LEVEL=error ~/.local/bin/mise x -- tuist generate -p /Users/admin/builds/HhgRYymL/0/veepee/offerdiscovery/products/front-mobile/ios/veepee/Projects/Veepee/ --no-open
[17:39:01]: ▸ Loading and constructing the graph
[17:39:01]: ▸ It might take a while if the cache is empty
[17:39:10]: ▸ ✖ Error
[17:39:10]: ▸ The data couldn’t be read because it is missing.
[17:39:10]: ▸ Sorry this didn’t work. Here’s what to try next:
[17:39:10]: ▸ If the error is actionable, address it
[17:39:10]: ▸ If the error is not actionable, let's discuss it in the <Troubleshooting & how to: https://community.tuist.dev/c/troubleshooting-how-to/6>
[17:39:10]: ▸ If you are very certain it's a bug, <file an issue: https://github.com/tuist/tuist>
[17:39:10]: ▸ Check out the logs at /Users/admin/.local/state/tuist/logs/2DEE4A41-25B8-48CE-9675-8A782E4FBF82.log
+--------------------------------------+
|             Lane Context             |
+------------------+-------------------+
| DEFAULT_PLATFORM | iOS               |
| PLATFORM_NAME    | iOS               |
| LANE_NAME        | ios ci_unit_tests |
+------------------+-------------------+
[17:39:10]: Called from Fastfile at line 839
[17:39:10]: ```
[17:39:10]:     837:	      sh(tuist_install_dependencies_command)
[17:39:10]:     838:	      sh(commp)
[17:39:10]:  => 839:	      sh(tuist_generate_command)
[17:39:10]:     840:	    end
[17:39:10]:     841:	  end
[17:39:10]: ```
[17:39:10]: Exit status of command 'MISE_LOG_LEVEL=error ~/.local/bin/mise x -- tuist generate -p /Users/admin/builds/HhgRYymL/0/veepee/offerdiscovery/products/front-mobile/ios/veepee/Projects/Veepee/ --no-open' was 1 instead of 0.
Loading and constructing the graph
It might take a while if the cache is empty
✖ Error 
  The data couldn’t be read because it is missing. 
  Sorry this didn’t work. Here’s what to try next: 
   ▸ If the error is actionable, address it
   ▸ If the error is not actionable, let's discuss it in the <Troubleshooting & how to: https://community.tuist.dev/c/troubleshooting-how-to/6>
   ▸ If you are very certain it's a bug, <file an issue: https://github.com/tuist/tuist>
   ▸ Check out the logs at /Users/admin/.local/state/tuist/logs/

[2DEE4A41-25B8-48CE-9675-8A782E4FBF82.log](https://github.com/user-attachments/files/23240801/2DEE4A41-25B8-48CE-9675-8A782E4FBF82.log)

.log

I’m attaching the corresponding log file

2DEE4A41-25B8-48CE-9675-8A782E4FBF82.log

For us the issue was apple.swift-protobuf being updated from 1.33.1 to 1.33.3 We reverted this back in our Package.resolvedand got it back working properly

{ “identity” : “apple.swift-protobuf”, “kind” : “registry”, “location” : “”, “state” : { “version” : “1.33.1” } }

Dude you saved my life.

We just merged this which should prevent this from happening again on your CI by ensuring builds run with the dependency versions locked by the Package.resolved. I’m now working on adding support for the .disableWarning setting that some packages started using.

@Nonouf does this solve the issue?

https://github.com/tuist/tuist/releases/tag/4.96.0

@pepicrft it does work now, but … we’re having 2 new issues :

1. By upgrading from 4.12.1 to 4.96.0, generating a project became very very slow now. We went from ~3 min to ~28 min.
2. We have one shared xcassets folder and different xcassets folder following the target. Generating the project now includes every xcassets in every targets.

I can open a new issue for the first point, but I’d appreciate some advice on how I can find some information on what’s going on.

For the second point, I suppose there has been a change in the way resources are configured. I’m looking into it …

Hey @Nonouf 👋🏼 Both, 3 min and 28 minutes are very off, which makes me think there might be something going on in the project. For context, we have projects with hundreds of modules with generations in the range of seconds. Since the sources are available, you can open them in Xcode, and run Tuist against your repository. That should shed some light over where the issue is. You can follow the steps to run Tuist here, and if you can’t parse the instruments data, you can send it over and I’ll look into it.

For the second point, I’d need a reproducible project and what you expect and what you get and I can take it from there.

Thanks @pepicrft! To give you some context, it’s a big legacy project that I migrated to Tuist back in 2023 using the v3 version. So there is currently only one giant module, with multiple targets.

I’m going to look into running Tuist from the sources, then I’ll get back to you.

@pepicrft Unfortunately using the sources didn’t help as I got the same logs than using the cli directly… but I still managed to fix the performance issue. It’s completely unrelated to this issue, but I share it because something definitely changed between these 2 versions (even though the problem comes from us).

We have one project with one big module, which contains a white label app. We then have 8 targets that share the same sources.

For each target, I specified the source paths as such :

Target.target(
     …
     sources: [
        .glob(“Sources/**", excluding: “**/Externals/AFolder/**/*.{m,h}”),
        .glob(“Sources/Externals/**", excluding: “**/Externals/AFolder/**/*.{m,h}”, compilerFlags: "-w"),
        .glob(“Sources/Network_deprecated/**", excluding: “**/Externals/AFolder/**/*.{m,h}”, compilerFlags: "-w”)
     ]
     …

What made things slow is the use of **/ a the root of thepath, which I can only suppose made Tuist look 3 times into each folder for every single target, starting from the root of the projet …

Now generating a project takes about 9 seconds on a cold run and 7s on a warm run.

Looking into the xcassets issue now. I’ll open another issue if needed. Thanks for the help.

Oh yeah! Globs can get super expensive. Our recommendation is always to avoid them, but if you can’t, then yeah, you need to make sure they don’t require traversing too many directories to resolve them.

Support for SwiftPM warning control settings (which should resolve the target build setting decoding error) is now available in 4.201.0-canary.8. Update to this version and let us know if you still see the issue.

The fix for decoding target build settings is now available in 4.201.0-canary.7. This resolves the parsing error where SwiftPM warning control settings were not properly recognized during project generation.

Update to 4.201.0-canary.7 to resolve this issue.

A fix for the SwiftPM warning control settings decoding issue is now available in version 4.201.0-canary.6. Update to this version to resolve the “Failed to decode target build setting” error.

Support for SwiftPM warning control settings is now available in 4.201.0-canary.9. The fix handles the new SwiftPM build settings format that uses ‘tool’ and ‘kind’ keys instead of ‘name’, resolving the decoding error when generating projects with packages using the newer format. Update to 4.201.0-canary.9 to get this fix.

The fix for the SwiftPM warning control settings decoding issue is now available in version 4.201.0-canary.13. Update to that version to resolve the target build setting decoding failure.

The fix for the target build setting decoding failure you reported is now available in 4.201.0-canary.12. This release includes support for SwiftPM warning control settings that should resolve the Failed to decode target build setting error you encountered. Update to this version to get the fix.

The fix for SwiftPM warning control settings decoding is now available in 4.201.0-canary.11. This addresses the “Failed to decode target build setting” error that occurred when parsing Package.swift manifests with newer SwiftPM format settings.

Update to 4.201.0-canary.11 to use this fix.

The SwiftPM warning control settings support in 4.201.0-canary.10 may help with the build setting decoding issue. Update and let us know if it resolves the problem.

Support for SwiftPM warning control settings is now available in 4.201.0-canary.18 and should resolve the target build setting decoding issue. Update to this version and try again.

The fix for SwiftPM warning control settings decoding is now available in 4.201.0-canary.17. Update to this version to resolve the target build setting decoding error.

The fix for the target build setting decoding failure is now available in 4.201.0-canary.16. This adds support for SwiftPM warning control settings that use the newer ‘tool’ and ‘kind’ keys. Update to this version.

The fix for the failed target build setting decoding issue is now available in 4.201.0-canary.15. The support for SwiftPM warning control settings includes fixes for properly handling target build settings that were causing decoding failures. Update to this version to use the fix.

The fix for the target build setting decoding issue is now available in version 4.201.0-canary.14. Update to this version to resolve the “Failed to decode target build setting” error when generating projects with certain Swift Package Manager configurations.

A fix for the target build setting decoding error (missing ‘name’ or ‘kind’ keys) is now available in 4.201.0-canary.19. This adds support for SwiftPM warning control settings and handles both Xcode 14+ and legacy format build settings. Update to 4.201.0-canary.19 to get this fix.