tuist cache fails to build SPM packages that use build tool plugins for codegen (e.g. aws-sdk-swift ≥1.7.x)

Metadata

Source

tuist/tuist #12446

Updated

Aug 18, 2026

Domains

Cache Generated projects

Details

What happened?

When warming the binary cache (tuist cache) for a project with a dependency on aws-sdk-swift (pinned to 1.7.53, which uses smithy-swift’s schema-based-serde codegen), the Binaries-Cache-iOS build fails to compile the InternalAWSCognitoIdentity/AWSCognitoIdentity targets with errors like type 'CognitoIdentityClient' has no member 'getCredentialsForIdentityOperation'.

The referenced members are never present in the checked-in source — smithy-swift generates them at build time via SmithyCodeGeneratorPlugin, an SPM build tool plugin (capability: .buildTool(), running the SmithyCodegenCLI executable). When Tuist converts the SPM package graph into native Xcode targets for the Binaries-Cache-iOS scheme, this build tool plugin does not appear to run (or its generated output isn’t added to the target’s compile sources), so the generated operation code is missing and every dependent compile fails.

Pinning aws-sdk-swift to 1.6.7 instead (which predates the plugin-based codegen switch, generating all operation code at package-authoring time) builds and caches successfully — 63 targets stored, 0 misses.

We hit this after bumping an unrelated leaf dependency (amplify-ui-swift-liveness 1.4.4 → 1.4.5), which transitively pulled a newer aws-sdk-swift/smithy-swift into the plugin-based codegen architecture and silently broke tuist cache for the whole AWS dependency subgraph, with no change to our own code.

How do we reproduce it?

tuist-buildtool-plugin-repro.zip

Minimal repro project attached/linked (single app target depending on AWSCognitoIdentity from aws-sdk-swift):

mise install       # installs the pinned Tuist version
tuist install       # resolves SPM dependencies
tuist generate --no-open
tuist cache

To see the control case succeed, edit Tuist/Package.swift to pin aws-sdk-swift to 1.6.7 instead of 1.7.53, then re-run the same three commands.

Error log

CognitoIdentityClient.swift:737:47: generic parameter 'InputType' could not be inferred
CognitoIdentityClient.swift:737:47: generic parameter 'OutputType' could not be inferred

✖ Error
  The command '/usr/bin/xcrun xcodebuild build -scheme Binaries-Cache-iOS -workspace .../App.xcworkspace -destination generic/platform=iOS Simulator ... -configuration Debug ...' terminated with the code 65:
  ** BUILD FAILED **
  The following build commands failed:
        SwiftCompile normal x86_64 CognitoIdentityClient.swift (in target 'InternalAWSCognitoIdentity' from project 'aws-sdk-swift')
        SwiftCompile normal arm64 CognitoIdentityClient.swift (in target 'InternalAWSCognitoIdentity' from project 'aws-sdk-swift')
        Building workspace App with scheme Binaries-Cache-iOS and configuration Debug
  (4 failures)

macOS version

26.6.1

Tuist version

4.204.0

Xcode version

26.6

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] Aug 18, 2026

@alexmx this is a documented limitation of Tuist’s XcodeProj-based integration: SPM build tool plugins are not supported through the Tuist/Package.swift + .external(name:) path [1].

Build tool plugins have no equivalent native Xcode project primitive. To support them, Tuist would need to evaluate the plugin’s Swift code, reproduce SwiftPM’s plugin context, discover commands, model declared inputs/outputs, and add generated files to the target graph — none of which it can do today [1]. This is also why there’s a related open issue (#11453) tracking crashes when external packages transitively depend on build-tool-plugin products.

The documented workaround is to declare the package using Xcode’s default integration in your project manifest’s packages array and attach the plugin with .package(product:type: .plugin):

let project = Project(
    name: "App",
    packages: [
        .remote(url: "https://github.com/aws-amplify/aws-sdk-swift", requirement: .exact("1.7.53")),
    ],
    targets: [
        .target(
            name: "App",
            dependencies: [
                .package(product: "AWSCognitoIdentity", type: .runtime),
            ]
        ),
    ]
)

The tradeoff is that Xcode owns plugin resolution, so tuist cache won’t be able to cache those targets — binary caching only works with the XcodeProj-based integration [2].

Your practical options:

Use Xcode’s default integration (packages array) for aws-sdk-swift, accepting those targets won’t be cacheable.
Pin to aws-sdk-swift ≤ 1.6.7, which predates the plugin-based codegen (as you’ve confirmed works).
Run smithy codegen outside the Xcode build (e.g., as a pre-build script or CI step), check in the generated sources, and consume them as regular files — then XcodeProj integration and caching work normally.

You may also want to try installing this debugging skill following these steps and using a coding agent to investigate whether there’s a viable project-level workaround for your specific setup. For a longer discussion on workarounds or future support, the community forum would be a good place to continue.

To reply, just mention @dosu.

Share context across your team and agents. Try Dosu.