tuist: two server canaries and a Helm chart release in under a day

The three most recent releases all landed on the same day

The release history is unusual in a way that is easy to miss when skimming. Three tags are visible: a Helm chart release, [email protected], on 2026-11-02, then two server canaries, [email protected] and [email protected], about twelve minutes apart on 2026-11-03. So the newest tags are per-component, with the server on a canary channel. The version numbers themselves are worth noting as a shape: a server 1.358 series and a Helm chart at 0.259 imply a very high release count, which is consistent with a project that ships continuously. The last push to the default branch was 2026-11-02, and the repository is not archived.

The project table lists twelve pieces across five languages

The development section describes the repository as a monorepo and then gives a table, which is the most useful thing in the readme because it describes the system rather than the marketing. The command line interface is Swift. The iOS and macOS app is Swift. The Android app is Kotlin with Compose. The Tuist server that hosts the cache, previews, analytics and dashboard is Elixir on Phoenix, and the Swift package registry service is also Elixir on Phoenix. The design system powering the web UI, Noora, is Elixir on Phoenix again. The cache mesh service for distributed cache traffic is Rust, named kura, and the hosted source code search service is Rust too. The Gradle plugin for Android and JVM builds is Kotlin. Atlas, the internal ops app for CRM, contracts, finance and go to market, is Elixir on Phoenix.

The declared primary language is Elixir while the product surface is Swift

Given that table, the recorded primary language for the repository is Elixir, and that is accurate as a count of projects rather than as a description of what a user installs. Four of the twelve entries are Elixir on Phoenix: the server, the registry, the design system and the internal ops app. The command line interface and the iOS and macOS app are Swift. So the largest group by project count is server-side Elixir, while the artifact a developer actually runs is compiled from Swift. That distinction matters when you are deciding where to file a bug or where a change has to land. The remaining projects are two Kotlin entries, the Android app and the Gradle plugin, and two Rust entries, the cache mesh and the code search service.

A Go workspace sits in the root of an Elixir-primary monorepo

The top level of the tree contains go.work and go.work.sum, which is a Go workspace definition, alongside a Kotlin Gradle plugin, two Elixir services, a Swift package manifest, two Rust services and an Elixir project directory. A Go workspace file is what lets several Go modules in a repository be developed and built together as a unit, so its presence means at least one of the Rust-adjacent or infrastructure pieces is not actually Rust, or that a tool inside the tree is written in Go. There is also a Grafana datasource, an infrastructure directory, a CI directory and a cache directory, so the deployment and observability side lives in the same repository as the product.

Two Xcode version files pin which toolchain the build expects

Two files sit side by side at the root, .xcode-version and .xcode-version-releases, and neither is standard Xcode configuration. The presence of two suggests one pins the version used for local development and the other records the versions each release was built against, which is the pattern a project needs when it publishes artifacts for several Xcode releases. Alongside them are .swiftformat and .swiftlint.yml for formatting and linting Swift, and .taplo.toml for TOML, which is a reasonable signal that the toolchain configuration is treated as part of the product.

The cache is the core and four other services assume you run a backend

The framing sentence puts the cache first: it reuses previously built artifacts across environments to speed up builds, and a suite of tools around it keeps them fast, reliable and observable. The readme opens by saying the tool works whether you build with Xcode, Gradle or Bazel, so the target is set by your existing build system rather than by a replacement for it. The project table says the Tuist server hosts the cache, previews, analytics and dashboard, and lists the registry as a separate Swift package registry service; which features need a server is the question to answer before adopting.

The company handbook and an internal CRM are checked into the product repository

Two entries in the project table are not infrastructure for the tool at all. One is a skills package described as the Tuist agent skills package, and the other is the company handbook, which the table lists alongside the command line interface and the server as a project in the monorepo. Atlas goes further: it is named the internal ops app for CRM, contracts, finance and go to market, built in Elixir on Phoenix like three of the server-side projects. Putting sales, contracts and finance tooling in the same repository as the build platform means the tree mixes product code with company operations, which has an obvious benefit in keeping context in one place and an obvious cost in what is in scope for a contributor. The readme also lists openness and community as cornerstones and points at a handbook site, a community forum and documentation as the places to start.

Editorial conclusion

tuist suits a platform team with more than one Apple or JVM codebase and a build time problem, since the cache and the selective testing are the parts that pay for themselves and the rest of the suite is optional. Two things to weigh first. Work out how much of the platform you are actually adopting, because the readme's project table says the Tuist server hosts the cache, previews, analytics and dashboard. And note what is in the repository, since an internal CRM covering contracts, finance and go to market shares a tree with the product code, which tells you the boundary between the company and the tool is not a hard one. A team with a single small project will not recover the cost of standing up the server side.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. tuist/tuist on GitHub