Hey everyone 
Last week we wrapped up our 4th cycle of 2025, and we’ll share more about what the team has shipped during the cycle in next week’s community call. I recommend everyone to attend because we’ve got a “One more thing” type of announcement that I believe you’ll all love (spoiler: we are bringing one of Tuist’s most awesome features to every Xcode project out there). If you can’t make it, that’s fine. We’ll record it and share it on social.
In this post I’d like to share with you what the team is going to be focusing on for the next 6 weeks. Let’s dive right in:
Authentication flexibility
We are moving away from project-scoped tokens with implicit permissions, to account-scoped ones that include explicit scopes and the projects they are bound to. You’ll be able to generate them easily through the dashboard, and use them as you wish. From the most obvious case, which is authenticating the interactions with the cache from the CLI, to building your own automation to pull your data from our REST API.
As Tuist keeps getting more powerful, we believe the API will play a key role and therefore it’s essential that the authentication options are flexible enough for developers to choose what suits them best.
Support hashing destinations when running snapshot tests
The result of some tests might be destination-dependent, like snapshot tests, and therefore we need to ensure the destination is incorporated into the hashing such that we store the results bound to the destination that was used to run them. We are going to expose an API for you to configure that behavior such that Tuist does it automatically.
Tuist-initiated Okta authentication
We have support for Okta via OAuth2, but the authentication process needs to be initiated from Okta, which among other things, makes it impossible to authenticate in our mobile and desktop apps using Okta. In this cycle we are going to change that by allowing you to initiate the Okta authentication flow right from our login page.
Test insights
We added build insights not too long ago as a solution to standardize and make available data from your Xcode builds. If you are not using it already, I’d recommend checking it out and adding it to your projects. It’s free and just takes one scheme post action. And if you are using generated projects, the process is even simpler. Did you know that we parse those beautiful formats .xcactivitylog and .xcresult to gather the data and push it to the server? Since we had to reverse-engineer the pbxproj format, this thing of reverse-engineering undocumented formats is becoming part of our day-to-day development.
Jokes aside! We are taking this further to do the same with your test data. Why? You might guess… Well, without data you can’t understand how your decisions impact the project and the developer experience of your developers. You can continue working blindly until the productivity is so bad that your leadership comes to you and suggests migrating to React Native to meet the organization’s demand, or you can respond with data and optimizations, and everyone will be happy.
Tests are like living organisms. They need to be nurtured. They need to be fast. They need to be reliable, and they need to run just when they have to so that things move quickly. Without data, this is impossible. We not only abstract the hassle of processing that data, but also the hassle of persisting it in ClickHouse so that you can query it, understand it over time, and get valuable insights, like which tests are frequently failing, or which ones take the longest to execute.
Support for regional storage of Tuist cache binaries
Tuist’s module-based caching is backed by Tigris, allowing us to serve the binaries closer to the locations where they are needed. This makes it possible to reduce the latencies quite significantly, but we want to take one step further here and allow customers to specify the region in which they’d like the artifacts to be persisted. Accounts and projects will be able to configure the region in which they’d like their binaries to be persisted and we’ll pass that over to Tigris.
API to read analytical data
We’ll provide APIs to export data from the Tuist server like runs, build, or test insights. And thanks to the account tokens that we are introducing, you’ll be able to interface with those new APIs using tokens generated through the new interface that we’ll build. Why? You might guess… You might already have some data processing pipeline or system in which you’d like to ingest this data. It’s your data at the end of the day, so you should be able to access it.
Moreover, this API can be accessed by our CLI to expose new commands, and our apps to bring some dashboard features down to the native clients. Or who knows… maybe developers build creative solutions interfacing with our API. It’s hard to foresee, but it’s definitely clear to us that we should invest more and more in making our API flexible.
Revamp the documentation home page
There are few places where developers usually land on Tuist. Our marketing site, whose revision will go live next week, our repository’s README.md, and our documentation page. Therefore it’s very important that those pages can hold the developers’ hands and navigate them to the right place that they are looking for, or answer any questions that they might have. With that in mind, we noticed that the home page of our documentation has a lot of room for improvement. We believe it’d benefit from being more visual and having a different structure that helps developers navigate to the right places in the docs. As the surface of what Tuist is capable of gets broader and broader, we can no longer assume a linear path in the way people will navigate the docs.
Run QA from the dashboard
If you haven’t played with QA yet, let us know. We are looking for feedback from real testing scenarios. I promise, it’ll blow your mind once you try it. If you are tired of maintaining acceptance tests, or your QA testing setup is not that scalable, you’ll like this one.
One of the things that you’ll notice is that the QA sessions are triggered from a comment in a PR. We want to make that more flexible and allow you to trigger the sessions from the dashboard. It’s simple. You find a preview that you’d like to QA, and you’ll have a form for triggering the build. After a while you’ll have the result of your testing ready for you to assess and decide on.
Package caching
Clean package resolution is slow. You can use the package registry to help there, but what if you didn’t have to? One of our customers gave us an amazing idea that we are going to bring to every Xcode developer out there. We’ll leverage our low-latency caching to cache the resolved dependencies of any Xcode project and restore them in any environment (e.g. CI or local). The resolved dependencies will be massaged to make the size smaller. We expect this to save you a couple of minutes (depending on how many dependencies you have) in every clean setup/build.
And that’s it for our next cycle! There are some other items that we are going to work on, but we are keeping them secret to add a bit of excitement to the solutions that we are putting out there. I’m here to answer any questions that you might have.
Thank you everyone for being there and supporting us in this journey! This keeps getting better every day.