As you may know, using Tuist today often involves migrating your Xcode projects or workspaces into what we call Tuist projects. With Tuist projects, we’ve conceptually simplified many complexities and enabled optimizations that wouldn’t have been possible otherwise. Both Xcode projects and Tuist projects are here to stay. However, for many organizations, replacing their Xcode projects or Swift Packages—even with their limitations—is not an option. So, how can we best support those organizations?
I believe it’s time to iterate on our model at Tuist. First, we need a shift in mindset. Rather than viewing Apple’s tools as flawed systems to abstract away, we should see them as platforms to extend. This subtle shift has significant implications: for one, developers would barely need to change anything in their setup. Additionally, we should embrace industry conventions as our defaults and share alternative ideas we believe are worth exploring, without trying to impose them. For example, we could provide a Fastlane lane so people can easily run Tuist from their existing Fastlane setups.
Last but not least, wherever possible, we should build features that work seamlessly with vanilla Xcode projects and workspaces, without requiring any migration. Tuist should feel plug-and-play—something a developer can try in a day and instantly gain value from.
We have several ideas for such features, and one of them is analytics. We’ll make these as actionable as possible, covering not only project insights but also builds, tests, and generated artifacts. With just one or two lines added to your project, you’ll get a beautiful dashboard to help optimize your development environment.
In the coming weeks and months, you’ll see this approach reflected throughout Tuist—from our documentation structure to our configuration model APIs. And of course, we’ll ensure everything remains backward-compatible.
Let me know if you have any questions.