Automations now offer a rolling-window option alongside the calendar window. Pick Last days to evaluate over a fixed period like 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.
The analytics card on the Quarantined Tests page now splits the count into three widgets: total quarantined, Muted, and Skipped. Each widget has its own value, trend, and a chart that switches when you click it, so it is easier to see whether the suite is leaning on muted failures or actively excluding tests from execution. Selecting a widget pins the chart to that mode and persists the selection in the URL for sharing.
The Selective Testing tab on a test run now exposes the same per-target subhashes the Module Cache tab already had. Expand a row to see exactly which inputs went into the hash — sources, dependencies, environment variables, project and target settings, Info.plist, and the rest — making it straightforward to pinpoint the input that drifted when a previously cached test target shows up as a miss. The card also gains a Copy as JSON action that snapshots every selective testing target with its hashes, ready to paste into a ticket or diff against another run.
Automations now have a Comparison dropdown alongside When, with 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.
Organizations can now use SCIM 2.0 to let identity providers such as Okta provision, update, and deprovision Tuist members automatically. Generate a SCIM bearer token from the Authentication settings page, configure your IdP with the SCIM endpoint URL, and assign users or groups from your IdP to keep Tuist membership in sync.
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.
Tuist now integrates with self-hosted GitHub Enterprise Server (GHES) instances. Switch to the Enterprise server tab on your organization's integrations page, enter your GHES base URL, and click install — Tuist routes you through GitHub's App manifest flow, which registers a fresh Tuist GitHub App on your GHES instance and hands the App's credentials back to Tuist. From there, comments, check runs, and repository connections all flow through your private GHES.
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.
Quarantined tests now have two modes: Muted (runs, failures masked, the existing behaviour) and Skipped (excluded from execution; xcodebuild gets -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.
The Test Cases page has a new "Test cases" widget that plots the number of distinct test cases with at least one run in the preceding 14 days. The Flaky Tests page has a matching "Flaky Tests" widget that plots the number of tests currently flagged as flaky over time, alongside the existing "Flaky Runs" metric. Click either widget to swap the chart.
Flaky-test handling used to be a fixed set of project toggles: auto-quarantine on or off, one threshold, one cooldown, one Slack channel. That made every team fit the same mould. Automations let you decide what "flaky enough to act on" means for your project, and what should happen when a test crosses that line — quarantine it, keep it green but flag it, ping a specific channel, or any combination — and how it should recover on its own. The engine is built to grow beyond flaky tests, so the same shape will cover more of your test-suite hygiene over time.
Test run details now show every device or simulator the run executed on, alongside the existing Mac host info. For multi-destination test plans, each destination is listed with its platform and OS version so you can see at a glance whether tests ran on iPhone, iPad, Apple TV, Apple Watch, or Vision Pro.
