Cache for any Xcode project

Today was an important day at Tuist. We released a major redesign of our marketing site and a caching solution that works with any Xcode projects, and we couldn't be more proud of our 4-person team pulling this off. We are building the company to be as agile as we can, and this result proves that.
Cache is one of our best-sold features and very instrumental in turning Tuist from a community-grown open source CLI into an open infrastructure for mobile developers. Who doesn't want faster builds, right? However, our implementation required teams to use generated projects, and this migration was only justifiable for large companies, so our reach was limited. We knew Apple was working on transitioning Xcode's build system and its derived data approach to a model similar to Bazel's, and that this would open the door for cache for everyone. We knew it was something to look into, and that it'd take years to reach the performance of our cache, but seeing other companies jump into it was a wake-up call for us.
I covered this in past blog posts, but the CI landscape is evolving rapidly. Many companies now have the incentive to provide elastic ephemeral Linux and macOS environments that can plug into GitHub Actions and GitLab CI as runners, resulting in better and cheaper environments. This shift means teams have more options than ever before. To differentiate, many providers are exploring additional value-adds like cache or competitive pricing. We've seen various approaches to this, and it's exciting because competition fosters innovation. This motivated us to dive into what we know best: reverse engineering Apple's tooling internals.
It took us a couple of weeks to have not only a functional version, but one with a great developer experience that would make it easy for anyone to adopt from any environment. In a world where environments are getting cheaper, we believe it's important to decouple the environment provider from the service provider and not discriminate based on developers' environments. They are environments at the end of the day. Throughout this work, we realized a few things.
The CLI, in which we invested for many years, and everything that makes it possible, including our open API and our OAuth2 authentication workflow whose session is automatically managed in the environment, plays a crucial role in bringing Tuist's value to the edge. We meet developers where they are. Our design philosophy centers on the command line, which feels natural for developers regardless of where they run their workflows. It's been 9 years of investment, and it's paying off.
Second, and as Marek pointed out in the blog post, there are improvements with the new cache capabilities, but they are modest compared to what you can achieve with what we call module cache at Tuist. We decided to take a transparent approach with a technical deep dive bringing clarity to how it works, how we've done the benchmark, and opening it up for anyone to get familiar with and, why not, even contribute to swift-build. We see learning and sharing as something positive, and we'd rather invest in the infrastructure that's needed to make it possible. We believe openness is a long-term advantage.
Last, and this is something I touched on in the context of making the code available, with this piece more value shifts to the infrastructure. The challenge will be more about how to bring the latency down than building a gRPC server itself. We'll spend the following months researching and investing in a multi-level cache that can serve assets as close to the environment as possible, even from local or private networks. Sure, we'll never be able to compete with the speed of I/O against a mounted volume in a CI environment, but as Apple improves the capability, we'll make it good enough that the value will outweigh the cost of being coupled to a specific provider. This is especially important in an environment where more companies are providing CI environments that you can plug into GitHub Actions and GitLab CI.
It's exciting times for faster and more reliable incremental builds that span across environments. Apple is building the foundation, and we are building the environment-agnostic infrastructure that not only gives the foundation superpowers but gives teams the agency to take back control over where their workflows should run. We'll also invest in collecting and presenting you with the best and most useful insights so Tuist can be your best buddy as you scale your Xcode app development.