Tuist uses your project's default branch as the baseline for analytics, insights, and comparisons, from bundle size checks to test reliability and flaky test detection. It was already configurable through the CLI, and now you can view and change it directly from your project's settings too. When you connect a GitHub repository, Tuist also adopts the repository's default branch automatically.
Module Cache can now cache framework targets that support your tests, even when they link XCTest or Swift Testing. This helps projects with shared assertion helpers, fixtures, or test utilities reuse binary cache artifacts instead of rebuilding those helper modules from source every time.
Test bundles themselves are still left out of the binary cache. The change only applies to regular framework products that tests depend on, so your test targets keep their normal behavior while their reusable support modules can benefit from local and remote cache hits.
Module Cache can now cache static and dynamic library targets, not only framework targets. Library products are warmed, stored, and consumed as XCFramework artifacts, including Swift modules and public headers, so projects with mixed framework and library graphs can reuse binary cache artifacts across local and CI builds.
Test bundles remain excluded from the binary cache, but reusable library targets that support tests can now benefit from the same cache flow as test-support frameworks.
Build and test times are coming to Grafana. The new Tuist data source plugin pulls the same p50, p90, p99, and average durations you see in your Tuist dashboard and renders them as native Grafana time series, so build and test performance can sit next to the rest of your observability. You configure it with a Tuist account token, then pick a project and an environment (CI or local) and the percentiles you want to chart. Project and environment are dashboard variables, so a single dashboard works across every project the token can reach, and you can watch how your pipelines trend as you optimize them.
The plugin is not published to the Grafana catalog yet. We are getting it ready for release and will update this entry once it is available.
Some tests are not intermittently flaky; they are broken, or failing so often that they drown out useful signal. Automations can now monitor Test reliability across branches and trigger when it drops below your chosen threshold. Pair it with actions like changing the test's quarantine state, marking it as flaky, or notifying Slack, so broken or consistently failing tests can be handled automatically.
When Tuist runs in GitHub Actions, it now writes a Tuist Run Report to the Actions job summary. The test and build results for the run show up right on the workflow run page, with a link to the full report on Tuist, and nothing extra to set up.
This is especially useful with merge queues. A merge queue run is not attached to a pull request, so there is no comment to post, and until now you had to wire up your own JUnit reporting to see results. The summary now shows up for every authenticated run, whether it came from a pull request or a queue.
Tuist can now use prebuilt libraries from Swift Package Manager dependencies when generating projects. This is especially useful for macro-heavy packages such as SwiftSyntax, where support libraries are large and expensive to build from source.
When a package provides prebuilt metadata, Tuist wires the generated project to the prebuilt library search paths, include paths, and linker flags instead of generating the corresponding source targets. Projects that depend on Swift macros can keep the same package workflow while avoiding unnecessary SwiftSyntax support builds in the generated Xcode project.
There is nothing new to configure for packages that expose the prebuilt metadata. Run tuist install and tuist generate as usual, and Tuist will use the available SwiftPM prebuilts during graph loading and project generation.
The Module Cache tab on a build run now appears for builds made straight from Xcode and reported with tuist inspect build, not only for tuist test and tuist xcodebuild build. You get the same breakdown of which modules were resolved from the local cache, the remote cache, or missed, together with the overall cache hit rate and each module's hash.
There is nothing new to configure. The breakdown reuses the graph that your last tuist generate already uploaded, so a build reported from Xcode points back at that generation instead of re-uploading anything on every build. The numbers reflect the project as it was generated, which is what you want for an incremental Xcode build.
Every Tuist Runner job now ships a Steps card and a Logs tab on its detail page. Each step expands to show only the lines that belong to it; ##[group]Run … blocks fold the same way they do in GitHub's own log UI, and ANSI escapes are rendered as colour instead of [36;1m…[0m artefacts. Line numbers restart at 1 per step so you can reference "line 14 of Run tests" without doing global arithmetic.
The new Logs tab is a live tail backed by ClickHouse: lines stream in while the job is running, full-log substring search works against every line (not just the tail you've loaded), and the Download logs button hands you a gzipped archive straight from S3 once the job completes. Timestamps are off by default and toggle to the full Tue, 02 Jun 2026 20:26:29 GMT format when you turn them on, so a copied line carries the date with it.
Test run filters now support excluding branches that contain a specific substring. Use the new "does not contain" branch operator in the dashboard, or the query=-git_branch~"gh-readonly-queue" expression in the REST API and list_test_runs MCP tool, to hide merge queue runs such as gh-readonly-queue while keeping the rest of the test history visible.
