Frequently asked questions
Managing Xcode projects is hard, especially once you go beyond a few developers working on a simple project with a handful of targets to larger team working on a workspace with several projects, each of which have several targets.
Moreover, managing large projects using the UI interface is error prone, and not very reproducible. Having a project definition in code or configuration helps make this more manageable. This is actually quite common in other places too e.g. Swift PM, Gradle for Android, Crates for Rust, CMake for c++ project etc...
Tuist helps you overcome scaling issues by abstracting you away from certain knowledge that Xcode expects your developers to have. With Tuist, your developers can be focused on building the app, rather than setting up the environment and project properly to get Xcode happy about it.
Not supporting Tuist in the future is as likely as Facebook not supporting React. Many things can happen and we can't make sure Tuist exists forever. For that reason, we have designed Tuist API in such way that your projects depend weakly on it. Your team is responsible for defining how the project should look, and Tuist takes that input, and generates an Xcode project that follows standard conventions. In case of Tuist not being maintained anymore, the generated project is a valid and standard project, which you can include in the git repository.
Moreover, Tuist is an open source community driven tool.
Swift Package Manager (SwiftPM) is the official tool from Apple for managing Swift packages. Although SwiftPM and Tuist have a similar design, their goal is different. The Swift Package Manager aims to facilitate the definition and usage of Swift packages, while Tuist facilitates the definition of projects (e.g. iOS apps projects) and the interactions with them. Developers continue to ask Apple for some integration with existing Xcode projects so you might expect some overlapping in the future.
Definitively. Although Tuist provides CLI commands such as a build and test, you can use Fastlane's gym and scan actions, or your own automation logic. You can work with the project that Tuist generates as if it was a project generated by Xcode, nothing changes.
First and foremost, because the manifest files like
Workspace.swift can be edited with Xcode, which helps the developers validate the syntax using the Swift type system. It also prevents developers from tweaking Tuist in any way. This might change in the future, and there'll be support for hooks where developers will have the flexibility to define custom actions.
They can, but there's no dependency management built in Tuist. Depending on how your project manages external dependencies, the integration process changes:
- Carthage: Since it generates precompiled framework, you can set your target up to depend on that framework. Tuist will set up the build settings and build phases for you.
- CocoaPods: The project manifest model doesn't support adding a CocoaPods dependency but you can call
pod installafter the project has been generated with Tuist. We have plans to improve this having support for it from the manifest.
- Swift Package Manager: Unfortunately, there's no support for integrating your projects with spm dependencies. We are waiting for Apple to do some work on that area to add the integration into Tuist.
Whether or not you check in your projects is up to you, as workflows vary from project to project. We recommend that you keep the projects under source control, and don't add it to your .gitignore. But ultimately this decision is up to you:
Benefits of checking in the projects
- After cloning the repository, the project can immediately build and run, even without having Tuist installed on the machine.
- The projects are guaranteed to be identical to those in the original installation after cloning the repo.
- The git conflict problems can be alleviated defining a custom merge driver that would generate the project when conflicts are detected.
Benefits of ignoring the projects
- There won't be any conflicts to deal with when performing source control operations, such as merging branches with different Pod versions.
That's on purpose. We could have exposed things like schemes, or the link frameworks build phase. However, we'd be offering an alternative syntax for defining Xcode projects, and that's not the goal of Tuist. We aim to provide a simple, convenient and scalable interface that abstracts from the implementation details. Whether you need to create a scheme to test a target, or add a copy frameworks build phase to embed your transitive dependencies. That's something you shouldn't have to worry about.
This approach might sound restrictive at first, but it allows us to have more control over the generated project, validate your input and generate an output that we feel confident about. We'd feel bad if we give you a project that doesn't compile and you need to spend time figuring out what's wrong.
If you'd like a more granular approach you can check out a tool like XcodeGen.