Tuist is a command line tool (CLI) that aims to facilitate the generation, maintenance, and interaction with Xcode projects. It’s distributed as a binary, which you can easily install and use without having to depend on other tools to manage dependencies (like you would do if the tool was written in other programming languages such as Ruby, or Java).
The first thing that we need to do to get started is installing the tool. There are two recommended ways of doing it: using Homebrew or running a script. In either way, you need to run the following commands in your terminal:
The process is relatively fast because we are actually not installing the tool. We are installing
tuistenv (which gets renamed to
tuist) when you install it.
A very common issue working on iOS projects is not having a reproducible environment. Very often, projects depend on things that should be installed by other tools. To give you an example, if your project depends on Fastlane, it probably depends on Bundler being installed in the system and a clean Ruby environment with the version that the project expects. If any of those things are missing or are not in a good state, it results in unexpected outputs and a really bad experience for your developers.
To avoid that, Tuist is self-contained and comes with
tuistenv which ensures that the right version is used. It manages different versions in your environment and runs the version your project is pinned to. Thanks to that, we ensure that anyone in your team will use the same version of Tuist.
In a more advanced section on the documentation, we’ll see the power of
tuistenv. For now, we’ll keep things simple and just assume that we are running Tuist directly.
Creating our first project
Now that we have Tuist installed, we can create our first project. Create a directory for your app:
And then run:
init command will bootstrap an iOS application, which includes the
Info.plist files, an
AppDelegate.swift, a tests file, and a
Project.swift that contains the definition of the project.
If you have used the Swift Package Manager before, the
Project.swiftfile is the equivalent to the
The definition file, also known as manifest, has the following structure:
Since we are defining an Xcode project, most of the properties might be familiar to you. There are some that are available which are not used from the manifest that you’ve got generated. You can check out the project reference to see all the public models that are available in the
We have the manifest and the project files, but something missing, the Xcode project. If we don’t have an Xcode project, we can’t use Xcode, because that’s the format that Xcode expects. Fortunately, Tuist comes with a command to generate projects and workspaces from your manifest files. If we run the following command in the terminal:
We’ll get a
MyApp.xcworkspace files. As we’ll see in the dependencies section, the workspace is necessary to add other projects
MyApp project is depending on.
If you open
MyApp.xcworkspace and try to run the
MyApp scheme, it should build the app and run it on the simulator 📱 successfully 🎉.
Editing the Project.swift
Did you realize that there’s a target,
MyAppDescription, which contains the manifest file? Thanks to the Swift types system and Xcode, you can edit the manifest file from Xcode and get syntax autocompletion, documentation and errors while you are modifying the definition. Isn’t it great?
In the next page, you’ll learn how to define dependencies between targets and with precompiled frameworks and libraries.
Got improvements? Help improve this document via sending PRs.