変更履歴

Finding the right preview build is easier across the Tuist apps and dashboard. Add release notes to tell testers what changed, then use search and tracks to narrow down the builds they want to try.

Captured on an iPhone 18 Pro simulator using example builds.

Build context at a glance

Attach plain-text release notes when sharing a preview. Put a build number or short summary on the first line, followed by any testing instructions:

tuist share App --track QA \
  --release-notes $'Build 204: sign-in fixes\nVerify checkout and payment processing'

Web and iOS preview lists show the first nonblank release-notes line, so testers can identify a build without opening its commit. Long summaries are truncated; full notes remain available on the detail page. Search on both platforms matches app names and the complete notes, including lines that are not visible in the list.

Search and filter on iOS

Choose a project, search for an app or something mentioned in its notes, and select a track such as QA, beta, or nightly. Each track pill shows its full-project build count, and each preview shows its track beside its commit hash.

Search and track filters work together across all pages. Counts stay project-wide as you filter, so you can see which other tracks have builds. Choose All to remove the track filter, or clear the search to remove the text filter. Pull down to refresh without losing either selection. If nothing matches, the empty state suggests adjusting the search or track instead of refreshing the same results.

Previews from every branch on macOS

The macOS app now discovers previews from every branch, even when the project has no default-branch preview. Selecting an app in the menu launches that app on the chosen device.

For self-hosted deployments, update the server, CLI, and companion app to use the new release-notes, search, and track-filtering features. See the app previews guide to get started.

Tuist now connects to native Cursor Origin repositories. Build results, test failures, flaky tests, app previews, and bundle-size changes appear together in a Tuist Run Report on the pull request. As more results arrive, Tuist updates the same comment instead of adding another notification.

The screenshot uses explicitly labeled demo data to illustrate the report.

To get started, open your Tuist account's Settings → Integrations, choose Connect under Origin, and approve repository access in Cursor. Then choose Add new project connection to link a Tuist project to one of the connected account's native repositories.

Your existing build and test workflows continue uploading results to Tuist. Installing the Origin app does not run those workflows or require access to your source code. GitHub mirrors continue using the GitHub integration, and results for superseded pull request commits do not overwrite the current report.

See the Origin integration guide for setup, result-upload requirements, and self-hosted configuration.

Cache volumes keep dependency directories between CI jobs. Until now, only successful jobs on the default branch saved their changes, so teams that don't run CI on the default branch after every merge saw their caches fall behind during the day.

You can now choose which branches save. Open Runners → Profiles, edit the profile your workflows use in runs-on:, and expand Save cache from. Jobs on each repository's default branch keep saving, and you can add branch names or patterns such as release/*, or * to let every branch in the repository save. To save only from the branches you add, turn off Default branch. The settings apply to every cache volume used by jobs on that profile, including the new volumes you get when your cache key changes.

Existing workflows keep working as before. Pull requests from forks never save. See the cache volumes guide for details.

Cache volumes keep dependency directories between CI jobs, and tools rarely clean up after themselves, so saved contents grow from run to run. Once a volume is nearly full, every job that mounts it has little room left to write, and jobs can fail with errors such as No space left on device.

Volumes now recover on their own. When a volume's saved contents reach 80% of its capacity and a job runs out of space on them, the next job starts with an empty volume and saves a fresh copy. Large caches that still leave jobs room to write keep their saved contents, and a full volume costs one failed job and one cold run instead of every job failing.

The volume's page in Runners → Volumes warns when its saved contents are nearly full. When a failed job filled one of its volumes, the job page shows which volume ran out of space, so a full disk no longer looks like an unrelated build failure.

To keep volumes small, use your tool's cache cleanup settings. See the cache volumes guide for details.

Tuist's Elixir integration can now reuse compiled dependencies through the same Kura REAPI cache as Bazel. Enable it with cache: true and the compile alias to automatically select supported dependencies. Declare additional compile-time inputs or exclude dependencies with non-deterministic compilation when needed. An input key maps to an ActionResult referencing a content-addressed dependency compilation bundle; clean builds can restore it without compiling that dependency again. Authentication, endpoint discovery and signed cache analytics use the existing shared APIs.

The Mix Cache page follows Xcode's layout, showing average and percentile build hit rates above Recent Builds. Transfer, latency and throughput retain real measurements and local-copy/remote-CAS provenance; legacy values stay unavailable rather than zero. Each build's Mix cache tab has task hits, misses, hit rate and download/upload totals, a lookup breakdown, latency percentiles and searchable task rows with copyable keys and Xcode-aligned CAS-only expanded rows. Expand tasks to follow their actual bundle hashes into CAS Outputs, whose graph, download/upload throughput and output table use Bazel's shared REAPI queries over Kura-signed records. Local copies never become invented remote output rows. Bypassed and already-current dependencies do not count as misses; avoided compilation time is an estimate, not elapsed build savings.

Caching remains opt-in and dependency-only. Unsupported native/custom compilation falls back to Mix. A verified local snapshot store covers unavailable remote endpoints, authentication and storage failures without hiding compiler errors. Checkout paths participate in keys by default; portability requires explicit opt-in because BEAMs can retain producer paths. Compilation bundles can also embed compile-time values, so audit selected dependencies and project cache access. See the Elixir cache guide for configuration and safety limits.

Tuist now supports the Program Status Protocol (OSC 7501), giving compatible terminals a reliable way to know what a command is doing without parsing its output.

Commands report working while they run, done when they succeed, and error when they fail. During browser sign-in, Tuist reports blocked with kind=auth until authentication completes, then returns to working. Supporting terminals can use these states for status indicators or notifications when a command finishes or needs your attention.

No configuration is required. Terminals without protocol support ignore the status messages, and redirected output, machine-readable output, quiet mode, and continuous integration runs remain unchanged.

Once action tables now show the readable names reported by Once, and source files link to your connected repository at the run's recorded revision. Search by an action name or source path to find the work you are looking for. Actions with many source files show a compact preview while keeping every path searchable.

Bazel cache actions can also show readable descriptions from an uploaded build profile when its output, target, and mnemonic metadata match the cache telemetry unambiguously. Search works with both these descriptions and the original mnemonics. Generated output paths are used only for correlation, not presented as repository source links.

Older clients and historical runs keep their existing labels when this metadata is unavailable. Cache keys, replay handling, and hit/miss counts are unchanged.

Cache volumes now support macOS runners on fleets where the feature is enabled. GitHub Actions, Buildkite, and GitLab CI jobs can keep dependency downloads between runs by attaching a volume with a stable key and directory, such as ~/.npm or ~/.gradle/caches.

Each job gets its own writable copy of the saved contents. Eligible successful jobs on the default branch save changes for future runs, while pull requests and parallel jobs can reuse the cache independently. Linux and macOS volumes stay separate, even when they use the same key.

Open Runners → Volumes to see macOS and Linux volumes together. Each volume has storage trends, cache hit rates, and a history of the jobs that mounted it. The existing Tuist and Xcode compilation cache also appears here as measurements arrive, alongside the volumes you add to your workflows.

On macOS, use volumes for download caches; node_modules and tools that replace their cache directory are not supported. The cache volumes guide covers setup for all three CI providers and how changes are saved.

You can now block a pull request when its bundle grows by more than a fixed size, such as 1.5 MB, instead of a percentage of the baseline. The allowed increase stays the same as your app grows.

In Settings → Bundles, add or edit a threshold, choose Install size or Download size, and select Absolute size (MB). MB uses decimal units: 1 MB = 1,000,000 bytes.

Existing percentage thresholds are unchanged, including fractional values such as 0.47%. Both types compare against the latest matching bundle on your baseline branch and keep the same GitHub check and approval flow.

See the bundle insights guide for configuration details.

Coding agents connected through Tuist's Model Context Protocol server can now subscribe to events when a test is marked flaky, a build or test run fails, or a Tuist runner job fails. The client chooses a project for build and test events or an account for runner jobs, and provides a verified callback. It controls which events reach it and what to do next.

Each event includes a resource identifier and a link to its details. The agent can use Tuist's existing tools to inspect the failure and start debugging. Subscriptions expire unless the client refreshes them, and delivery stops if the relevant access is removed.