Sorting by these columns lets you review the lists chronologically: surface the tests that have been parked the longest and are overdue for a fix, or check what was quarantined most recently and why.
]]>Targets can now declare these values through additionalHashingInputs:
let hashingInputs: [Target.HashingInput] = [
.glob("Templates/Model.stencil"),
.glob("Codegen"),
.glob("Config/**/*.json"),
.environmentVariable("FEATURE_CONFIGURATION"),
.string("generator-v2"),
.script("codegen --version"),
]
Pass the array to Target.target(additionalHashingInputs:). Exact files, directories, and glob patterns contribute their contents. Environment variables contribute their current value, strings contribute their literal value, and scripts contribute their standard output. When any declared input changes, the target hash changes and Tuist rebuilds the artifact instead of restoring stale cached output.
Install @tuist/noora from the Node Package Manager package registry, then import the design tokens and component registration bundle once in your browser entry point:
import "@tuist/noora/tokens.css";
import "@tuist/noora/web-components";
For a quick browser-only prototype, a content delivery network such as jsDelivr can serve the same published files directly from the Node Package Manager package:
<link
rel="stylesheet"
href="https://cdn.jsdelivr.net/npm/@tuist/noora@latest/priv/static/tokens.css"
/>
<script
type="module"
src="https://cdn.jsdelivr.net/npm/@tuist/noora@latest/priv/static/noora-web-components.js"
></script>
The @latest addresses are convenient for prototypes. Pin an exact published version when using Noora in production.
You can then use Noora custom elements directly:
<noora-button variant="primary">Create project</noora-button>
Interactive components use standard browser events where they fit and documented noora-* custom events for structured interactions. For example:
document.querySelector("noora-select").addEventListener("noora-select", (event) => {
console.log(event.detail.value);
});
The package also includes TypeScript declarations, a Custom Elements Manifest, and generated reference documentation for attributes, properties, slots, styling parts, and events.
]]>Tuist now exposes the shared Hypertext Transfer Protocol (HTTP) retry policy through two environment variables:
TUIST_HTTP_MAXIMUM_RETRY_COUNT controls how many retries follow the initial attempt. It defaults to 3, setting it to 0 disables retries, and values above 10 are capped at 10.TUIST_HTTP_RETRY_BASE_DELAY_IN_MILLISECONDS controls the initial exponential backoff delay. It defaults to 100 milliseconds and values above 30000 are capped at 30000 milliseconds.The base delay now correctly starts at 100 milliseconds rather than roughly one millisecond. Each retry doubles the delay and adds up to one base delay of random jitter, helping clients avoid retrying in lockstep after a shared network failure. Individual retry delays never exceed 30 seconds.
Self-hosted operators can now pair a longer resource timeout with fewer attempts, or increase the base delay to spread retries during congestion. Invalid values fall back to the defaults.
]]>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:
{
"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:
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.
]]>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.
]]>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.
]]>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.
]]>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.
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.
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.
Project.packages:
let project = Project(
name: "App",
packages: [
.package(path: "Package", traits: ["NativeIntegration"]),
]
)
The project description interface follows Swift Package Manager's Package.Dependency model. Traits are typed values, .defaults enables the package's default traits, and an empty set disables them. Package traits require Xcode 26.4 or later, and existing package declarations continue to work through the deprecated compatibility initializer.
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. ]]>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.
]]>
You can also resend any invitation from the same row. Resending refreshes the invite link and validity window, making it easier to recover from missed or stale invitations without revoking and recreating the invite.
]]>
This is useful when CI is your trusted cache producer. CI OIDC logins and scoped account tokens can write to the cache, while members using normal login sessions stay read-only. That helps teams avoid one-off local uploads, reduce cache storage growth, and remove upload wait time from developer machines.
]]>.xctest bundle won't load, or the app under test never launches, so the tests never get to run at all. Xcode treats these as errors rather than test failures, and now Tuist does too: run and target-level errors show up in a dedicated Errors section on the test run page, each with the target that hit it and the underlying message.
Pulling these out of your test cases keeps your counts honest, an error is no longer miscounted as a failed test, and makes the two kinds of problem easy to tell apart. We also renamed the failures section to Test Failures, so each reads as what it is: Errors stopped your tests from running, Test Failures are the assertions that didn't hold.
]]>
Every run's Module Cache tab surfaces the network side of your cache. Alongside cache hits, misses, and hit rate, you'll now see:
Use it to right-size your runner profiles: move a job that barely touches the CPU onto a smaller machine, or give a job pinned at 100% more cores so it ships faster. Hover a step and the charts highlight that window, so you can tell which step pinned the CPU or filled the disk.
]]>
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.
]]>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.
]]>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.
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.
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.
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.
##[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.
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.
Each workflow_job has its own detail page mirroring GitHub's /<owner>/<repo>/actions/runs/<run_id>/job/<job_id> shape (so the Tuist URL and the GitHub URL nest the same way), with a timeline card for queue / claim / runtime / total durations and a deep link back to GitHub.
Compute minutes — the metered signal we bill against — roll up from the Pod's wall-clock lifetime rather than GitHub's workflow_job timestamps, the same way Namespace and Blacksmith account for their runners. Every dashboard widget that aggregates duration is scoped by the same Repository / Workflow / Platform / date-range filters as the table below it, so the chart and the rows always represent the same window.
]]>
The tooltip is available in both the Test History tab and the compact history section on the test case overview.
Marked as flaky, Unmarked as flaky, or state transitions to Enabled / Muted / Skipped — and the configured actions fire right away. The common shape: someone manually marks a flaky test, the automation immediately mutes it and pings Slack. Each automation-driven change also lands on the test case timeline attributed back to the rule that triggered it, so you can always see which automation moved a test and why.
30d, or Rolling window to evaluate over the last N runs of each test case — useful when test volume varies day-to-day and a fixed time window over- or under-reacts to recent activity. The same dropdown is wired into Recovery so you can wait either for X days or for N new runs without a re-trigger before recovery actions fire.
Greater or equal, Greater than, Less than, and Less or equal. Pair it with a "Less than" comparison and an Unmark as flaky action to clean up stale flaky labels — including ones set manually or by an automation you've since removed — without touching tests that are still flaking.
SCIM provisioning works alongside SSO: SCIM manages membership lifecycle, while SSO controls sign-in. Deprovisioned members are removed from the organization, preserving their user record and historical work without disabling access to other Tuist organizations.
GitHub Apps are scoped to a single GitHub instance, so the github.com Tuist App can't be installed on a GHES instance — every customer registers their own copy. The credentials Tuist receives from the manifest exchange are stored encrypted per-installation. No env vars or Tuist server configuration changes are needed.
-skip-testing and the Gradle plugin filters with excludeTestsMatching). Pick the mode from the test case dropdown, filter by it on the Quarantined Tests page, or have an automation set it for you.
HTTPS_PROXY or HTTP_PROXY is set in the environment, Tuist now automatically routes the HTTP connections it manages (cache, previews, analytics, registry access, and the calls the Gradle plugin makes back to Tuist services) through that proxy. Nothing to configure: the CLI and Gradle plugin pick up the variable and use it. ]]>
@Test(arguments:)). Each argument variant is tracked individually with its own status, failures, and attachments, giving you per-argument visibility into what passed and what failed.
tuist setup insights to enable metric collection. Gradle builds collect metrics automatically through the plugin.
assembleRelease, connectedAndroidTest), making it easy to distinguish between different build types in CI environments with multiple builds.
This first release includes:
/mcp with proper bearer challenges.list_projectslist_test_cases (with optional flaky filter)get_test_caseget_test_runget_test_case_runfix_flaky_test) that guides agents through diagnosing and fixing flaky tests.This gives agents enough context and tooling to inspect flaky tests and drill down into run-level failure details from Tuist.
]]>.ips crash log is also available for download.
Additionally, the crash report is available in the CLI (tuist test case show <test-case-run-id>), which makes the crash report available to agents when for example fixing flaky tests.
Use TUIST_BUILD_TAGS or TUIST_BUILD_TAG_* for tags, and TUIST_BUILD_VALUE_* for key-value pairs.
Filter your build analytics by tag in the dashboard:
View tags and custom values in the build detail page:
xcodebuild test $(tuist test case list --skip-testing).
You can now organize your previews into named tracks like beta, nightly, or internal:
tuist share App --track beta
Tracks make it easy to group previews by purpose and filter them in the dashboard.
The new Tuist SDK enables your app to detect when a newer preview version is available and notify users - keeping testers on the latest build.
import TuistSDK
struct MyApp: App {
var body: some Scene {
WindowGroup {
ContentView()
.task {
TuistSDK(
fullHandle: "myorg/myapp",
apiKey: "your-api-key"
)
.monitorPreviewUpdates()
}
}
}
}
The SDK checks for updates within the same preview track. When you share with --track beta, the SDK notifies about newer builds on that track. Update checking is automatically disabled on simulators and App Store builds.
See the Previews documentation for more details.
]]>tuist inspect dependencies command that combines implicit and redundant dependency checks in a single invocation. This makes it ~2x faster by loading your project graph only once.
# Run both checks (default)
tuist inspect dependencies
# Run specific checks
tuist inspect dependencies --only implicit
tuist inspect dependencies --only redundant
The previous tuist inspect implicit-imports and tuist inspect redundant-imports commands still work but are deprecated in favor of the new unified command.
tuist auth login in your CI workflow.
name: Build
on: [push]
permissions:
id-token: write
contents: read
jobs:
build:
runs-on: macos-latest
steps:
- uses: actions/checkout@v4
- uses: jdx/mise-action@v2
- run: tuist auth login
- run: tuist generate
OIDC authentication is currently supported on GitHub Actions, CircleCI, and Bitrise. See the CI integration documentation for setup instructions.
]]>tuist account tokens create my-account --scopes project:cache:read project:cache:write --name ci-cache-token --expires 1y
Account tokens support various scopes covering cache, previews, builds, tests, bundles, registry, and account management. You can also set expiration dates and restrict tokens to specific projects within an account.
]]>
only-external (default), all-possible, or none, or define your own custom profiles in Tuist Config.
Read more about cache profiles in our documentation.
tuist test:
tuist test --skip-ui-tests
Now, we're bringing the some convenience flag for unit tests:
tuist test --skip-unit-tests
This way, you can easily have separate CI pipelines for UI and unit tests, such as when you don't want to run your UI tests for every PR but instead nightly.
]]>Read more about it in our blog post.
However, each bundle type can have a slightly different bundle size. While we recommend to primarily use the .ipa bundle type as the install and download size is the most accurate representation of what users will experience, the other types might be useful to recognize a spike in the bundle size early.
To streamline seeing a graph for a specific bundle type, we've added the option to filter by .ipa, .app, or .xcarchive:
This feature supports:
# List bundles in the current project
tuist bundle list
# List bundles in a specific project
tuist bundle list --project account/project
# Output bundle list as JSON for scripting
tuist bundle list --json
# View detailed information about a specific bundle
tuist bundle show {id}
These commands handle authentication and session management automatically, making it easy to integrate bundle operations into your CI/CD pipelines and custom automation workflows.
]]>Add this setting to your Tuist.swift configuration:
// Tuist.swift
import ProjectDescription
let tuist = Tuist(
project: .tuist(
cacheOptions: .options(
keepSourceTargets: true
)
)
)
When enabled, Tuist generates:
-Cached scheme containing all source targets isolated from the main dependency graphThis allows you to switch between optimized binary builds and full source access without regenerating your project.
Note: These source targets are for inspection and debugging only. If you modify their sources, you'll need to regenerate your project to reconcile the changes with the dependency graph.
]]>.pbxproj files. While we initially postponed support since these conflicts weren't frequent in our workflow, user feedback revealed another compelling benefit: buildable folders eliminate the need to regenerate projects when files are added outside of Xcode's UI—particularly valuable for automated agents and CI/CD pipelines.
Based on this feedback, we've now added support for buildable folders. If you're currently using Target.sources and Target.resources, you can migrate to the new Target.buildableFolders property to define buildable folders for your targets.
Note: Xcode's synchronized groups (the underlying implementation of buildable folders) support "exceptions"—files or folders that can be excluded from synchronization. While we don't support exceptions yet, we'll add this feature based on user demand.
]]>Previously, releasing new versions of Tuist required manual intervention from maintainers. This created bottlenecks and delays in getting new features and fixes to users. Now, we've implemented an automated release pipeline that:
Each component (CLI, Server, and macOS app) now has its own release pipeline that:
feat(cli): for CLI changes, feat(app): for app changes)We're using git cliff with custom configurations for each component:
(cli) scope or no scope(server) scope(app) scopeThe pipelines run on GitHub Actions and handle everything from version bumping to updating package managers like Homebrew.
This automation represents our commitment to making Tuist more accessible and reducing barriers for both contributors and users. We believe that great developer tools should be easy to contribute to and quick to deliver value.
]]>To achieve this, we’ve introduced Noora{:target="_blank"}—a design system for building CLIs in Swift. This Swift package provides themable components designed specifically for CLI interfaces. While the current selection of components is limited, we plan to gradually expand it by extracting more components from our work at Tuist.
If you’re building a CLI in Swift, we encourage you to explore the documentation{:target="_blank"}. We’d love to hear your feedback and welcome contributions to make Noora even better. If there’s a specific component you need, feel free to open an issue or submit a PR!
Transitioning from Tuist Air to Tuist Pro is now simpler—just add a payment method, and you'll only be charged for usage exceeding the defined thresholds. To make everything clearer, we've included a table outlining how the usage of various features is measured.
Looking ahead, we plan to provide examples, an estimation calculator, and tools to help you set usage limits, so you can stay within your budget and enjoy peace of mind.
]]>As part of this work we've also:
The design of the website has been done by Guinda Studio and it's publicly available.
]]>