سجل التغييرات

WebMCP lets a web page offer tools to the agent built into the browser. In a browser that supports it, Tuist's pages now register Tuist's MCP tools, so you don't need to add an MCP server first.

• Website and documentation: the agent can search Tuist's documentation and source code, without you signing in.
• Dashboard: once you're signed in, an account's pages offer the read-only tools coding agents use, so the agent can look up that account's projects, builds, test runs, bundles and previews. The calls run as you and only reach the account you're looking at. When you switch accounts, the tools switch with you.

Tools that create, change or delete data aren't offered in the browser, because the agent gets these tools without you choosing to add them and reads content that builds and tests produce. To use those tools, connect an MCP client to Tuist's MCP endpoint. If an organization enforces single sign-on, sign in to the dashboard with its provider to use its tools.

Organizations that enforce single sign-on already required it on their dashboard. Signing in to the Tuist CLI, the Tuist app, an MCP client or the API reference creates a credential that acts for you in every organization you belong to, so that now requires it too: if you signed in another way, Tuist sends you to your organization's provider first, and sign-in with an email and password or with Apple is refused.

The check also runs whenever one of these clients renews its credential. Existing credentials keep working if you have signed in through your organization's provider before. Otherwise they keep renewing for four weeks, and then the client asks you to sign in again; signing in through your provider once in that time, on the dashboard or with tuist auth login, avoids it. If you belong to several organizations that enforce single sign-on, one session can't satisfy all of them, so ask an organization admin for help.

Coding agents connected to the hosted Tuist MCP endpoint can now use a report_feedback tool when a Tuist tool or prompt does not work the way they expected: a confusing or wrong result, an error, missing data, an unclear parameter, or a capability they needed but could not find.

Agents suggest a report and send it only once you agree. Each report describes what was expected, what actually happened, and optionally a suggestion for a better tool, and it can name the account and project the problem happened in. The report opens a conversation with Tuist support under your name, so we can follow up with you by email and turn the feedback into improvements to the tools your agents rely on.

Reports should not include source code, secrets, or personal data. The tool is available to agents signed in to a Tuist account.

Build pages for Xcode, Gradle, Bazel, and Mix now have a Download trace button in the header whenever the build has a timeline. It downloads the build's recorded steps as a trace file that you can open at ui.perfetto.dev, chrome://tracing, or Perfetto's trace_processor. Steps are laid out in lanes by how many ran at the same time, so the number of lanes shows the build's peak parallelism. CPU and memory appear as counter tracks when the build recorded machine metrics.

Coding agents connected to the Tuist MCP server can use the new get_build_trace tool to get the same file. It returns a download link that is valid for one hour, so an agent can fetch the trace with curl, query it, or hand it to you to explore in Perfetto. The trace contains the same steps as the build's Timeline tab, without logs.

We have released security updates in response to the eMudhra certificate compromise. We recommend upgrading each Tuist component you use to the patched release listed below.

What is the risk?

When an application connects over HTTPS, it checks a certificate to confirm that it is talking to the right server. Certificate authorities are the organizations trusted to vouch for those certificates.

Compromised eMudhra certificate keys can be used to create forged certificates that some applications still trust. An attacker who can intercept a connection could use one to impersonate the intended server and read or change data sent over that connection, including credentials. This is often called a man-in-the-middle attack.

The problem concerns how applications verify the other end of a connection, not a break in TLS encryption itself. Different applications can use different certificate stores, so updating a browser or an operating system alone does not necessarily protect every application.

What we changed

The updates reject certificate chains that use the affected keys and update shipped certificate stores where applicable. Normal certificate and hostname verification remain enabled, and unrelated private certificate authorities remain supported.

The fix is available in these stable patch releases:

These versions identify the patched releases on their respective stable release lines. Updating a self-hosted server does not update installed clients, and updating a client does not update a self-hosted server.

What you should do

• Upgrade each component you use, including versions pinned in CI and project dependencies.
• Restart running clients and replace or recreate server and Kura containers with the fixed versions. Changing an image tag does not update an already-running container. Follow your normal upgrade and rollout checks.
• Keep your operating system and TLS libraries updated as well.
• If an endpoint starts failing certificate checks, repair its certificate chain. Do not disable certificate verification to work around the error.

If you need the fix backported to an older release line, contact us with the component and version you run.

What about past connections?

The updates address the risk of future connections trusting the affected keys. They do not establish whether a past connection was intercepted. Certificate-based impersonation may not leave a clear trace in application logs, so an absence of reports or log entries would not prove that no interception occurred.

If you suspect exposure, contact us so we can help assess your situation and any additional steps needed.

Once application artifacts can now appear in your Tuist project's Previews, using existing project access and distribution. Supported outputs include verified Android APKs and ad-hoc signed Apple simulator and macOS applications. Physical-device Apple distribution remains a separate signing workflow.

With Once 0.74.0 or later, configure artifact publication and explicitly authorize each target's destination once. Selected successful builds can then publish automatically, including builds restored from cache. Replaying the same retained publication does not upload or create another preview. Ordinary builds remain unpublished unless you opt in and authorize the destination.

Publication confirms artifact storage; preview processing follows asynchronously. Project previews use the project's default visibility, while the complete generic artifact closure stays private.

See the Once preview guide for setup, eligibility, and retention.

Tuist Previews now support macOS application bundles and command-line tools, alongside iOS and Android apps. Share a build from a branch or pull request so teammates can try it without rebuilding locally or replacing an installed CLI.

tuist share path/to/MyApp.app
tuist share path/to/distribution --executable bin/my-tool

Recipients run the preview with tuist run, forwarding CLI arguments after --:

tuist run {preview-url} -- --help

Distributions keep their bundled resources and libraries, while execution preserves the recipient's working directory, environment, terminal input/output, and exit status. Tuist selects a build compatible with the recipient's operating system and CPU architecture.

Package the dependencies your tool needs; previews do not bundle them automatically. macOS signing requirements and Linux system-library compatibility still apply. Desktop previews run as your user and are not sandboxed, so only run builds you trust.

See Supported preview types for packaging and Run previews with the CLI for usage details.

Getting feedback on a change shouldn't require everyone to build it themselves. Bazel and Gradle projects can now share apps and native command-line tools directly through Tuist Previews, so teammates can try a build without setting up the project.

With Gradle, run ./gradlew :app:tuistShareDebug --track nightly for an Android app, or ./gradlew :app:tuistShareMainDebug for a native C++ or Swift application. With Bazel, add a preview target alongside your Android app, Apple simulator or macOS app, or executable, then run it with --publish --project account/project.

Native command-line previews include their declared runtime dependencies, so recipients can run the packaged tool outside your build directory. Both workflows use your existing Tuist authentication and project access, without a separate CLI upload step.

You stay in control of what reaches your team: ordinary builds never publish previews. When you do share a build, it appears alongside your project's other previews, with the same visibility and distribution settings.

Get started with the Gradle preview guide or Bazel preview guide, then share a link so teammates can run the preview.

You can now turn Run report comments on or off in Project Settings → Integrations → GitHub. Existing integrated projects keep comments enabled, and each project controls its own preference.

Turning comments off keeps your repository connection, build and test uploads, and CI job summaries. Existing comments remain on GitHub.

Module caching for generated Xcode projects now supports --destination simulator and --destination device when warming and generating. Cache only the iOS slices you need for supported modules, then add missing slices later without rebuilding cached ones.

Both modes preserve native macOS targets, including macros. The default, --destination all, keeps all declared destinations, including Mac Catalyst.

See the module cache guide for usage and support limits.