This canary release adds release channels for the Tuist CLI, improves the binary cache and dependency handling, and fixes several generation and test reliability issues.
New release channels
- The Tuist CLI is now published through canary, release candidate, and stable channels. Canary versions ship per commit to main, stable versions are promoted after an RC soak.
tuist@latestresolves to the latest stable release, so you can pin to a recommended build while early adopters use canaries.
Cache and module cache improvements
- You can now cache static and dynamic library products as binary XCFrameworks in the module cache, alongside frameworks. Public headers and Swift module directories are preserved so generated targets can still compile against restored libraries.
- Cache warming no longer parses Xcode activity logs to track per-target build times, removing a source of failures when activity logs were missing or unparseable.
- The Bazel credential helper now refreshes access tokens within a 60 second safety margin of expiry, preventing mid-build UNAUTHENTICATED errors during long remote-cache builds.
- SwiftPM static library artifact bundles are now supported.
Dependency and generation fixes
.protofiles are now treated as source files, so Xcode build tool plugins such as gRPC Swift generators receive them as target inputs.- SwiftPM packages using newer warning-control APIs (
treatAllWarnings,treatWarning,enableWarning) can now be loaded and mapped into Xcode build settings correctly. tuist inspect dependenciesnow detects implicit imports of modules exposed by SwiftPM binary/XCFramework dependencies.- A stack overflow that could crash
tuist generateon large dependency graphs has been fixed by replacing recursive graph traversals with iterative implementations. - Generated module map files now keep stable modification times across warm project generation, so incremental builds are no longer invalidated when the module map contents are unchanged.
Test reliability
tuist testnow isolates hostless test bundles from app-hosted ones by running the generated project schemes separately when the workspace scheme mixes both types, avoiding xctest bootstrap crashes.- Suite-granularity test sharding now selects Swift Testing suites correctly by using
-only-testingarguments instead ofOnlyTestIdentifiersin the.xctestrunfile, which previously skipped Swift Testing tests silently.