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