Air now emails all organization admins and personal account owners at 80% and 100% of their monthly cache or runner allowance. Each email shows current usage, the reset date, and a link to upgrade to Pro, helping you avoid interruptions.
Small source edits can produce large compilation outputs. Tuist's Xcode cache now uses content-defined chunking with compatible cache servers to avoid transferring unchanged parts of those outputs.
Uploads send only chunks the server is missing. Downloads reuse verified chunks retained on your machine, fetch the missing pieces, and reconstruct the exact original output. The bounded local chunk cache survives cleaning DerivedData and restarting the cache service. Existing clients and unsupported servers continue to use ordinary whole-output transfers.
In local generated-fixture benchmarks, changing one C function reduced its object's transfer payload by 47.4%, and renaming one property in a large Swift module reduced its payload by 27.8%. These measure transferred bytes, not build-time improvements; savings depend on the output, the edit, and which chunks remain cached. Compiler invalidation is unchanged.
See the Xcode cache guide for how chunk reuse works and how to configure existing and Tuist-generated projects.
A slow build tells you where to start looking. The new Tasks page shows which Gradle tasks take the most time across builds, how often they execute, and how often they hit the cache.
Sort tasks by cumulative time to find repeated work that adds up, or compare p50, p90, and p99 durations to spot tasks with slow outliers. Filter by branch or environment to focus on the builds you want to improve.
Select a widget to explore execution trends, cache hit rates, or average and percentile durations over time. Open a task to inspect its individual executions, including outcomes and durations, then inspect an execution’s cache behavior and timing. Execution details link to the build behind them and back to the task overview.
Find it under Builds > Tasks in your Gradle project.
Large build outputs often change only in a few places, but traditional remote caches store every new version as a completely separate object. Kura now supports Bazel's content-defined remote cache chunking. The client splits a large output at stable content boundaries, uploads only chunks the cache does not already have, and records a compact recipe that reconstructs the original bytes.
This can reduce storage growth and upload work for successive versions of large artifacts while preserving the same verified content digest. Kura reconstructs downloads as a bounded stream, verifies every new recipe before accepting it, and safely falls back to a cache miss when a node cannot read the recipe. The capability is enabled by default for Bazel clients that negotiate it, while operators can temporarily disable new recipe writes during a reader-first fleet upgrade.
Tuist Runners now take jobs from Buildkite. Connect a cluster under Settings › Integrations with a cluster agent token, create a self-hosted queue named after a runner profile such as tuist-macos, and target it from a step with agents: { queue: tuist-macos }.
Jobs run on the same macOS and Linux fleet as GitHub Actions jobs and show up under Runners with their logs and duration. The guide walks through the setup.
Bazel projects now show completed builds and tests alongside the build systems already supported by Tuist. Each invocation includes its command, targets, result, duration, processor time, action counts, package counts, and metadata reported by Bazel.
The new cache view connects action-cache and content-cache requests to the invocation that produced them. It shows hit rates, transfer volume, latency, throughput, action names, target labels, and individual request outcomes.
Existing Bazel projects receive these views automatically after configuring Tuist as their build event and remote cache service.
Module Cache reported how often the cache was hit, but not which modules were responsible. The new Modules page ranks every module by cache misses, with its hit rate and how many modules have to be rebuilt when it changes.
Each miss carries a reason. Changed means the module's own content moved, upstream means only a dependency did, and cold means there was nothing to compare against. Upstream misses are the ones better module boundaries can remove.
Opening a module adds every build it took part in, filterable by branch, commit SHA or reason, so a high upstream share leads to the commits behind it. Dependents needs the dependency edges newer CLI versions send; everything else works with the data the CLI already reports.
Find it under Module Cache › Modules.
A test that only fails now and then usually reaches your default branch before anyone notices. Tuist can now rerun the test cases a branch adds, several times each in a fresh process, and flag the ones that pass and fail on the same commit.
Enable it with a mode. report warns about each flaky test case and leaves your run's own result alone. enforce fails the run instead.
tuist xcodebuild test --stress-new-tests report -scheme MyScheme
Gradle takes the same modes through a stressNewTests block in settings.gradle.kts, and both read TUIST_TEST_STRESS_NEW_TESTS so you can vary the mode per CI lane. A fast test case earns ten reruns and a slow one fewer, and the pass stops at 200 test cases or ten minutes.
Learn more in the flaky tests documentation.
The Linux runner catalog topped out at 32 GB of memory. There is now a 16 vCPU / 64 GB shape, the new ceiling.
Pick it when you create or edit a Linux profile. Jobs that exhausted memory on the 32 GB shape — Android release builds running Gradle and Kotlin daemons are the common case — fit without tuning heap sizes down. Existing profiles keep the shape they were created with.
Learn more in the runner profiles documentation.
Gradle Build Insights now supports user-defined tags and key-value metadata from settings.gradle.kts or environment variables. Filter builds by tag in the dashboard and inspect metadata values on each build's detail page.