変更履歴

Noora is now available as standards-based web components. They share the design tokens, visual language, and component behavior used by Noora’s Phoenix LiveView components, while remaining usable from plain Hypertext Markup Language or any browser framework.

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.

A longer resource timeout can keep a slow but progressing cache download from falling back to a source build. Until now, however, every failed request still used three fixed retries. Raising the timeout could therefore turn one stalled transfer into up to four long waits, with no way to adjust that tradeoff.

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.

Until now, the only way to get a run's dashboard URLs out of a CI job was to read them off the log. On GitHub Actions the job summary covered it, but everywhere else you were left matching the log text with a regex, which quietly breaks whenever the wording or the URL shape changes.

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.

Tuist now supports the complete auth.md authentication lifecycle for coding agents. An unauthenticated agent can discover instructions from the Tuist deployment it is connecting to, register, ask you to approve a six-digit code in Tuist, and receive a scoped credential after approval.

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.

Coding agents connected to the hosted Tuist Model Context Protocol endpoint can now use the 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.

Account tokens can now be managed directly from the Tuist dashboard. Generate scoped tokens for CI and automation, choose whether they can access every project or only selected projects, and set an optional expiration without reaching for the CLI.

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.

Tuist Runner jobs now include a Terminal tab while they are running. Use it to inspect the live job environment, run diagnostic commands, and recover context without waiting for another workflow attempt.

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.

Tuist Runners now enforce account-level CPU and memory concurrency limits independently for macOS and Linux. Jobs that would exceed the available capacity remain queued until resources become available, preventing a single workload from monopolizing the shared runner fleet.

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.

Tuist projects that use Xcode's native package integration can now select Swift package traits directly in 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.