Changelog

tuist install now uses SwifterPM by default to fetch and restore your Swift package dependencies. Resolution stays with the Swift Package Manager, while restoration links checkouts back to a global content-addressable store instead of copying them into every worktree. Warm restores drop to sub-second, and you stop paying for gigabytes of duplicated checkouts across worktrees.

This used to be opt-in through TUIST_USE_SWIFTERPM=1; now it's on by default. If you hit a package graph SwifterPM doesn't handle yet, set TUIST_USE_SWIFTERPM=0 to fall back to SwiftPM, and please open an issue so we can fix it.

Read more about how SwifterPM works in the announcement blog post.

Coding agents connected to the hosted Tuist Model Context Protocol endpoint can now use the ask_tuist prompt to answer questions about Tuist with evidence from both public material and the current implementation.

The prompt starts with documentation, reference material, releases, community discussions, and issues. When the answer depends on current defaults, configuration, feature gates, or error handling, the agent can search the Tuist source tree, discover nearby files, and read focused line ranges. Source results link to the exact repository revision so answers remain verifiable.

All source access is read-only and bounded. Searches, file listings, line ranges, execution time, scanned bytes, and returned text have hard limits, and partial results are reported explicitly.

Account tokens can now be managed directly from the Tuist dashboard. Generate scoped tokens for CI and automation, choose whether they can access every project or only selected projects, and set an optional expiration without reaching for the CLI.

The dashboard shows each token with a masked prefix hint, links to a detail page with its permissions and project access, and keeps revocation close to the token you are rotating. Newly generated token values are still shown once, so they can be stored securely before closing the dialog.

Tuist Runner jobs now include a Terminal tab while they are running. Use it to inspect the live job environment, run diagnostic commands, and recover context without waiting for another workflow attempt.

The same session is available from your local terminal with tuist runner ssh <job>, so you can use the dashboard when you want a quick browser shell or stay in your local terminal for deeper debugging.

Tuist Runners now enforce account-level CPU and memory concurrency limits independently for macOS and Linux. Jobs that would exceed the available capacity remain queued until resources become available, preventing a single workload from monopolizing the shared runner fleet.

The Runners dashboard shows hourly peak CPU and memory usage, with red bars for hours when a limit was reached. Limits can be tuned per account as runner needs grow.

Coding agents connected to the hosted Tuist MCP endpoint can now use a search_tuist tool to search Tuist's documentation, ProjectDescription API reference, GitHub releases, community forum, and GitHub issues in one call. Release results include product, version, and publication details, with prereleases available when requested. The tool is backed by the same search engine that powers the docs website, returns cited links for every result, and can be scoped to a single source. Agents get grounded answers about Tuist without relying on stale training data.

Self-hosted Tuist instances can now automatically clean up artifact files from object storage. Operators can set independent retention windows for cache artifacts, app previews, build archives, run artifacts, test attachments, and shard bundles.

Configure the windows through the Helm chart:

server:
  artifactRetentionDays:
    cacheArtifacts: 30
    appPreviews: 30
    buildArchives: 60
    runArtifacts: 30
    testAttachments: 30
    shardBundles: 14

Each artifact family also has its own environment variable for deployments that do not use Helm. Leaving a family unset or blank keeps its cleanup disabled. Cleanup removes artifact files only and preserves the associated PostgreSQL and ClickHouse metadata used by dashboards and analytics.

Build and test run pages now show a CI Details card whenever Tuist can match the insight to a Tuist Runner job. The card includes the workflow, job, runner profile, queue time, CI job duration, and the exact step that produced the build or test insight.

Runner job details now connect the CI run with the build and test insight data it produced. The new Insights card sits between the job summary and machine metrics, so you can see the build, test, cache, and selective-testing context before diving into CPU, memory, network, or step logs.

Tuist Runner jobs on macOS now include an Interactive tab while the job is running. Open it to see the live runner desktop over VNC, click through macOS prompts, inspect simulator state, or debug anything that is easier to understand visually than from logs alone.