Tuist

Tuist

Changelog

Product

Until now, the only way to get a run's dashboard URLs out of a CI job was to read them off the log. On GitHub Actions the job summary covered it, but everywhere else you were left matching the log text with a regex, which quietly breaks whenever the wording or the URL shape changes.

tuist test, tuist xcodebuild test, and tuist xcodebuild build now take a --run-report-path (or TUIST_RUN_REPORT_PATH), and write a JSON report of the run to it:

json
{
  "runId": "...",
  "status": "success",
  "runURL": "https://tuist.dev/acme/app/runs/123",
  "testRunURL": "https://tuist.dev/acme/app/tests/456",
  "buildRunURL": "https://tuist.dev/acme/app/builds/789",
  "testRuns": [
    { "scheme": "App", "succeeded": true, "totalTests": 10, "skippedTests": 2, "ranTests": 8, "failedTestNames": [] }
  ],
  "buildRuns": [{ "scheme": "App", "succeeded": true, "durationInSeconds": 432 }]
}

Every URL the run produced is included, so a command that both builds and tests gives you both links — something the log could never do, because it only ever printed one of them.

On GitLab, that makes the links available to the rest of the pipeline:

yaml
test:
  script:
    - tuist test --run-report-path tuist-run.json
    - echo "TUIST_TEST_RUN_URL=$(jq -r '.testRunURL // empty' tuist-run.json)" >> run.env
  artifacts:
    reports:
      dotenv: run.env

The report is a supported format, documented in the Continuous Integration guide, rather than something you reverse-engineer from the logs.

Product

Tuist now supports the complete auth.md authentication lifecycle for coding agents. An unauthenticated agent can discover instructions from the Tuist deployment it is connecting to, register, ask you to approve a six-digit code in Tuist, and receive a scoped credential after approval.

The flow works with Claude Code, Codex, OpenCode, and Pi when they connect to Tuist's Model Context Protocol server. Credentials expire automatically, can be revoked, and remain bound to the Tuist deployment that issued them.

Once connected, an agent can list the accounts available to you, create the correct project, guide a Gradle integration, and verify remote-cache behavior through Tuist before reporting that the setup is complete.

Product

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.

Product

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.

Product

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.

Account token settings in the Tuist dashboard with scoped token creation and existing token details

Product

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.

A running Tuist Runner job with the Terminal tab open, showing an interactive shell prompt and command output inside the dashboard

Product

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.

The Tuist Runners dashboard showing hourly macOS CPU and memory concurrency usage, with red bars marking when the configured limits were reached

Product

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.

Product

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:

yaml
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.

Product

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.

A build run detail page with Build Details followed by a CI Details card linking to the Tuist Runner workflow, job, profile, queue time, CI job duration, and matched step