変更履歴

Test run and build run pages now have a PR button in the header, next to CI Run, so you can open the pull request a run came from on any tab.

Tuist reads the pull request number from the Git reference your CI reports, such as refs/pull/123/merge on GitHub Actions, and links to the GitHub repository connected to your project, including GitHub Enterprise Server. The button shows up only for runs from a pull request in a project with a connected repository.

Organizations that set up single sign-on with Okta or a custom OAuth 2.0 provider before login email domains were introduced now find their domain already filled in under Authentication settings, together with the text record to publish. Add the record to your domain's DNS and click Verify domain. Once verified, members can find your provider from the login page by entering their email, existing Tuist accounts are linked to your provider when they sign in, and single sign-on enforcement, if enabled, also applies to new sign-ups from your domain.

Nothing changes until you verify: sign-in, enforcement, and automatic enrollment keep working as they do today. Verifying also limits automatic enrollment to addresses on your domain, rather than any address your provider reports.

Domains verified from now on are also re-checked daily, so keep the record published. If the record stops resolving, the settings show Verification expiring along with the record to publish again. The domain stays verified for 14 days, so a temporary DNS problem does not interrupt sign-in.

GitHub treats repository owner and repository names without regard to capitalization, and Tuist now does the same when exchanging an OpenID Connect token for a CI access token. A project connected as Tuist/Example continues to authenticate workflows that report tuist/example.

Tuist also refuses to issue a CI token when the same GitHub repository is connected to projects in different Tuist accounts. The integration settings identify the affected accounts so you can remove the extra connection and restore authentication. This keeps every CI token scoped to one Tuist account.

When adding a project connection, Tuist verifies that the selected repository is available to that account's GitHub App before saving it.

The Tuist Server and Kura images on GHCR now follow the same three-channel release train that the Tuist CLI has been on for a while. Instead of a single stable image cut on every merge, self-hosted operators can pick the channel that matches how close to the edge they want to run.

• ghcr.io/tuist/tuist:X.Y.0-canary.N is published on every merge to main that touches the server. Canaries are the bleeding edge, marked as GitHub prereleases, and never move :latest. Pin them explicitly if you want to track main.
• ghcr.io/tuist/tuist:X.Y.0-rc.N is published every Monday at 06:00 UTC from a releases/server-X.Y.x branch cut off main. Release candidates soak for a week; fixes ride onto the release branch as cherry-pick pull requests before the next -rc.(N+1) is cut.
• ghcr.io/tuist/tuist:X.Y.0 is the stable release, published the following Monday when the previous week's release candidate is promoted. Only stable releases move :latest, and only stable releases are picked up by mise or any other package manager that excludes prereleases by default.

Kura ships on exactly the same cadence: ghcr.io/tuist/kura:X.Y.0-canary.N, -rc.N, and stable move in lockstep with the server's train, and both trains fire on the same Monday morning as the CLI's promote job.

If you currently pin :latest, nothing changes for you today: :latest will keep tracking the newest stable, just on a weekly rhythm rather than a per-merge one. If you want the bleeding edge or a soaked candidate, the new tags are yours to pin.

GitHub Actions, Buildkite, and GitLab CI jobs on Tuist Linux runners can now reuse dependency directories with cache volumes on fleets where the feature is enabled. Use the GitHub action, Buildkite plugin, or GitLab attachment command. Choose a cache key and a directory, such as Gradle's dependency cache, and each job gets its own writable copy without downloading and extracting a cache archive.

Eligible successful jobs on the default branch save changes for future runs. Pull requests can reuse the cache in private copies, so parallel jobs can work independently. Volumes start with a 20 GB capacity and expire after seven days without a job mount.

The new Runners → Volumes page brings storage trends, cache hit rates, and job history together. Open a volume to see which workflows used it, follow a job back to its volumes, or clear its saved contents to start fresh.

See the setup guide to add a volume to your workflow. This first version supports Linux; macOS support will follow separately.

Xcode 27.2 introduces a new on-disk format for .xcodeproj bundles: a JSON5 file called project.xcproj that replaces the classic OpenStep project.pbxproj. The format is documented at apple/xcode-project-format, and while it's still marked experimental, it already delivers what most teams have been asking for from .pbxproj for years: smaller, more readable diffs and far fewer merge conflicts.

Tuist now lets you opt into it from your Tuist.swift:

import ProjectDescription

let tuist = Tuist(
    project: .tuist(
        generationOptions: .options(
            projectFormat: .xcproj
        )
    )
)

Every .xcodeproj Tuist generates for that workspace will be written as project.xcproj. The default stays .pbxproj, so nothing changes until you flip the option.

Because the format is still experimental in Xcode itself, you should treat this as an opt in for teams that are already on Xcode 27.2 across local development and CI. Earlier Xcode versions cannot read project.xcproj, so make sure every machine that opens the workspace, including runners, is on 27.2 or later before you turn it on.

Tuist now supports Google One Tap. When you visit the marketing site, login page, or sign-up page in a supported browser such as Chrome, you can choose your Google account from the browser's built-in prompt to continue to Tuist.

Existing users are signed in, while new users continue through account setup. The prompt appears when your browser and Google account settings allow it. You can dismiss it and use any of the existing sign-in options.

Test automations can now act on tests that already meet your conditions. Select Apply to existing matches when creating or editing an automation, and see how many tests currently match before saving. By default, actions still run only for new matches.

We’ve also simplified the editor with collapsible condition, action, and recovery sections, each with a concise configuration summary.

When two runs produce different hashes for the same target, the details should help explain what changed. Expand a target in Module Cache or Selective Testing to see its direct target dependencies by name, with links to each module's details. The combined Dependencies hash remains available, so you can spot changes even when the dependency names stay the same.

The destination list now reflects the platforms used to compute the hash. This matters when an external library supports several platforms but a particular project uses only some of them. Details also include embedded-product references, foreign-build inputs, and UI-test device and runtime inputs when reported by the CLI.

Copy as JSON includes the dependency names and individual hash inputs for comparing runs. Inputs that older CLI versions did not report remain unavailable.

The Tuist cache now negotiates the zstd compressor on both ByteStream transfers and BatchUpdateBlobs/BatchReadBlobs, so cache uploads and downloads from Bazel move meaningfully fewer bytes over the network on typical action outputs.

Cache contents on disk are unchanged: compression is a wire-only concern, verified against the same content digest Bazel already sends, so cache accounting and deduplication behave exactly as before. Bazel opts into wire compression via --remote_cache_compression=true, and tuist bazel setup now writes that flag into the generated .bazelrc.tuist — so re-running setup, or picking up the credential helper's next update pass, is enough for existing projects to start using it. Older clients keep working with uncompressed transfers.