更新紀錄

Every CI job runs on a fresh virtual machine, so actions/checkout clones your repository from scratch each time, Git LFS files included. On a large repository with LFS, that step alone can take minutes.

With cached checkouts, each runner host keeps your repository checked out on a cache volume named checkout. A macOS job starts with that copy mounted at its workspace, and the standard actions/checkout action finds the repository already there: it fetches only the commits and LFS files that changed, and rewrites only the files that differ. In our tests, checking out a repository with 2,000 LFS files went from about 65 seconds to under 10, mounting included.

Your workflows don't change. The runner host builds the cached copy from the checkouts your own jobs already do, verifies everything it takes from them, and never needs extra GitHub permissions. Pull requests start from the cached copy too, while only jobs on your default branch move it forward. The first job of a repository on each host checks out as before.

Cached checkouts work with GitHub Actions on macOS profiles and the default workspace path. They are on by default; to turn them off, open Runners → Profiles, edit the macOS profile your workflows use in runs-on:, and turn off Cached checkouts. The checkout volume appears next to your other volumes under Runners → Volumes, where clearing it rebuilds the copy from your next jobs.

Cache volumes keep dependency directories between CI jobs. Until now, only successful jobs on the default branch saved their changes, so pull requests kept starting from whatever the default branch last saved.

With GitHub Actions, every successful job from your repository now saves its changes, including pull requests from the same repository. Pull requests from forks and pull_request_target jobs never save. A job that doesn't change a volume leaves the saved version in place.

To save only from some branches, open Runners → Profiles, edit the profile your workflows use in runs-on:, expand Save cache from, and turn on Limit to specific branches. You can then keep the default branch and add branch names or patterns such as release/*. Profiles that already limit saving to specific branches keep their settings. Buildkite and GitLab CI keep saving from the default branch. See the cache volumes guide for details.

You can now link a Tuist project to a GitHub repository without opening the dashboard. Run tuist project repository connect owner/name, call PUT /api/projects/{account_handle}/{project_handle}/vcs-connection, or use the connect_project_repository Model Context Protocol tool. The repository must be one your GitHub App installation can access, and the project adopts its default branch. Account tokens need the project:admin:write scope. tuist project repository disconnect and the matching endpoint and tool remove the link.

Cargo builds, Mix builds and Once runs are now readable outside the dashboard too. Run tuist build cargo list, tuist build mix list or tuist build once list (and show for one build or run), use the list and detail endpoints under /api/projects/{account_handle}/{project_handle}/cargo/builds, /mix/builds and /once/runs, or the list_cargo_builds, get_cargo_build, list_mix_builds, get_mix_build, list_once_runs and get_once_run tools.

See the GitHub integration guide and the Model Context Protocol guide for details.

You can now install the Tuist app directly from Cursor Origin or GitHub and finish connecting it in Tuist. After signing in, choose the Tuist organization or personal account to connect. The chooser only lists accounts you can administer; if there is just one, Tuist connects it automatically. GitHub organization installations must be connected by a GitHub organization owner.

If you start from Settings → Integrations in Tuist, your selected organization is retained, so there is no extra selection step. GitHub Enterprise Server continues using the App registration flow started in Tuist.

See the Origin integration guide or GitHub integration guide to get started. Self-hosted administrators should also review the updated GitHub App settings, including the additional OAuth callback and organization membership permission.

New Tuist CLI releases include signed Packslip manifests that mise can use to authenticate the publisher and verify downloads. Before installing Tuist, mise verifies the GitHub release-workflow identity and checks the selected archive against its signed digest.

Packslip support is built into mise 2026.9.2 and newer; no separate Packslip CLI or experimental setting is required. Opt in with:

mise use packslip:github.com/tuist/tuist@latest

Use the explicit packslip: identifier for manifest verification. The mise use tuist shorthand currently uses mise's Aqua backend; it does not automatically switch to Packslip when the manifest is published.

Each new canary, release candidate, stable release, and backport includes a packslip.sigstore.json file on its GitHub release. The manifest covers the universal macOS archive and the Linux x86_64 and ARM64 archives, so mise can select the download for your platform.

Existing installation methods continue to work. Previously published releases are not retroactively signed.

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.

The Xcode build list API now supports date ranges, CI filtering, and cursor pagination for exporting build history to tools such as BigQuery. Use from and to Unix timestamps to select an inclusive creation-time range, and is_ci=false to focus on local builds.

Follow pagination_metadata.end_cursor with after to fetch older builds without new uploads shifting page boundaries. Use before with start_cursor to navigate back. Pages can contain up to 1,000 builds. Existing clients keep their first-page metadata and offset pagination. The initial response also includes cursors: omit page and pass after or before to continue with stable cursor pagination.

Build list and detail responses also include started_at, the actual build start recorded in newly processed activity logs. This is separate from upload time (inserted_at) and stays null for historical builds or reports without a recorded start time.

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.