What are we?

Yesterday, I came across the following tweet which made me think for a while:

Some developers are seeing Tuist as a combination of XcodeGen + Fastlane. That probably helps people give sense to some of Tuist’s functionality, but I don’t like that as way to describe the goal of this project. I captured a bit of what’s Tuist goal on this tweet, and I’d like to bring it to this discussion too.

We are a tool that aims to own complexities from Xcode projects to provide simple interfaces, workflows, and APIs to make the development of apps for Apple platforms conventional.

The way we own complexity is by generating projects that are described using a simple API (i.e. manifest files). This is the part where people might confuse us as another project generator, but that’s not what we are. Project generation is a mean and not an end. We are all motivated to make development with Xcode and scaling up projects easy and approachable to anyone in the team — even if you are not a tooling/infrastructure engineer.

As you might know, inconveniences and complexities not only come from Xcode projects, which can accumulate a lot of complexity over the years but from other areas like:

  • Configuring the environment for signing apps and make sure projects are properly configured for signing.
  • Installing tools in the environment that are necessary for the project to work. Make sure the installation is deterministic and reproducible in any other environment.
  • Maintaining Fastfiles, ensuring that they are readable and well-structured and not a big mess as they tend to grow into.

That having said, I don’t think the label of project generator or automation tool is appropriate and accurately describes what we are. Labels might constrain the vision that we have for the project, and I wouldn’t want Tuist to end up there. Xcode projects can easily gain a lot of complexity that we would like us to help users deal with

1 Like

I can answer a bit for why we chose Tuist over XcodeGen, and that might help this.

  • Quite literally the biggest reason is the advantages of the Swift-based DSL. We had some thoughts of using Buck/Bazel and have had the project building in various POC states of it (can’t ship because of different reasons so have to stay with xcodebuild), and one of the big benefits of those systems is Skylark allowing for expressive approaches. Tuist lets you do the same thing with Swift, which is the common language of the team and for some of our junior engineers the only language they’ve ever even written.

  • The DSL and the ability to template out projects while still having control (at least within what Tuist allows) is a good balance.

  • This isn’t unique to Tuist, but I think the way it is built lends it a little easier to do smarter things with CI/CD based on disk system changes than other comparable systems.

Signing wasn’t really in the picture. I think we’re still not sure the best way to manage that.

No Fastlane functionality is useful to use here, so weird to consider this as having much to do with it. Fastlane also is a project that’s quite broad in scope, so the focus (or lack thereof) is different.

Anyways that’s just some random thoughts during lunch.

1 Like