A couple of months ago, we announced that we’d start working in 6-week cycles (more on it in our handbook), a time frame we considered long enough to deliver meaningful value, and short enough to keep focus and momentum. Having these fixed cycles makes things predictable for you since you’ll know when significant new improvements will be released.
We start the first cycle of the year today, so I’d like to share with you what we decided to work on and why.
1. Finish up the dashboard redesign
Our current dashboard was “designed”, if we are allowed to use design for that, by @marekfort and me using a pre-made Figma template. Despite doing our best, the result wasn’t something we were happy with. That made us uncomfortable because it diminished the value perceived by users who had gotten used to the design excellence of tools like Vercel, Linear, or Supabase. @asmit took the design lead role at the company, embarked on building a build system, Noora, upon which he’d later design the new dashboard, and soon after @cschmatzler started working on materializing all the design work. For the past weeks, @marekfort has been helping too, and we are close to feature-parity with a new design. I think you’ll all love it.
We’ll complete, release, and announce the work as part of this cycle. I couldn’t be more excited about this because so much attention to detail has gone into it. We have more pages designed for features we plan to implement, but we’ll implement those as part of other projects. If you want to get a sneak peek of the design, here are some pages:
Design is central to shaping Tuist, and we want it to be one of our strengths and one of the reasons people decide to use Tuist.
@cschmatzler and @asmit will champion this effort with active contributions from @marekfort
2. Build insights
You might know that Xcode builds output a file, .xcactivity log, with a summary from your build. This can be useful for understanding your builds. However, it suffers from two things:
- It’s not developer-friendly, so you must resort to community tools to parse it.
- It’s not accessible, so once your build is complete, for example, in a CI environment, the file is gone, destroying the environment in which it was generated.
- In isolation, it provides little value; valuable insights come when you standardize, contextualize, and compare the information across time and builds. This was the premise of XCMetrics, which some organizations still use today.
We want Tuist to help you understand your builds so that you can identify opportunities for optimizations and improvements. Think of it as incorporating XCMetrics capabilities into the Tuist platform without you having to self-host anything, with a much better design and actionable metrics. We already took the first steps to report the information to the server, so you can see how your times evolve, and we want to go a bit further and build a better representation of the metadata contained in it placing a strong focus on what you can do with the data.
@marekfort will take the lead on this one.
3. Bundle insights
Although Tuist has the tools in place to understand your projects and your builds and provide you with actionable insights, there are some analytics that we can only provide by analyzing the result of your compilation. The bundles that your compilation generates.
As part of this cycle, we plan to change that. We’ll open-source a Swift Package that proposes a schema for a bundle analysis and provides the tool to generate a report from any Apple bundle. We are doing this because we want to foster innovation around this space and see how people can think creatively about the results of compilations.
Tuist will then provide a workflow for pushing to the server. As I mentioned earlier, the usefulness of Tuist lies in standardizing the data, storing it contextualized over time so that you can compare it, and giving you a nice interface for understanding the evolution of your bundles.
At the end of this cycle, you can report bundle analysis with a single command and get valuable insights on the server.
@cschmatzler will be leading this effort.
4. Test insights
A healthy test suite correlates to a productive team and better apps; however, the tools to ensure a healthy test suite are not there. Therefore, we’ll invest in providing the teams with the tools.
At the end of the cycle, they can identify which tests are the most flaky. Therefore, they should be looked into because they constantly block developers when merging PRs, and understanding how test selection impacts the time it takes to test suites.
@marekfort will take the lead on this one.
5. Cache insights
Binary caching is one of our most loved features. It helps teams skip compilation steps in clean builds, saving time and money. However, how much time they are saving is a question that they still struggle to answer, making the ROI unclear and challenging our conversations with them. Why should I pay for Tuist?
We are going to change that. You’ll see how much time you save (approximately) per build, day, week, and month. You’ll be able to filter that per environment. At the end of the cycle, answering “how much time did I save in CI this month?” is something you should be able to answer.
I’ll take the lead on this one.
6. Landing page redesign
With the rollout of the new dashboard, the current landing page will look a bit off. With a better understanding of the Tuist platform and its capabilities, @asmit is ready to elevate the design craft of our website and bring the same level of excellence that he brought to the dashboard. As part of that work, we’ll revisit our information hierarchy and roll out any necessary improvements to make Tuist easier to understand and our content easier to navigate.
Closing words
In addition to the above, we’ll continue to provide support and address any critical issues that prevent people from using Tuist and taking full advantage of it. Moreover, we are doing some “side quest” explorations of pieces that will be foundational in the problems that we want to solve in the future:
- Content-addressable stores (CAS)
- Remote Containers as a Service (RCaaS). We made this name up, but I think it’s cool.
So, expect our open-source work and content on the above subjects.
Do you have any questions about the above projects? We’ll be happy to answer them.