I’m Pedro, one of the maintainers of Tuist and the person that put the first building blocks to make this tool possible.
I started back when I worked at SoundCloud. There, we were going through some challenges that show up when you are scaling up your team and project: high build times, slow indexing in Xcode, random compilation issues, tough upgrades of the Swift version…
We decided to change the architecture to what we called µFeatures. The architecture optimized for build and test times, and ensured good practices to architect the different business domains of the product. The team was very happy with the result of the migration, but we realized that one of the biggest downsides was having to maintain a large dependency graph whose nodes were Xcode projects representing each of the domains.
That motivated me to start building Tuist in Swift. I started by building XcodeProj, a Swift library to read, update, and write Xcode projects (the only good library for that at that time was the one that CocoaPods had written in Ruby). Right after, I started building Tuist putting the focus on simplifying Xcode intricacies.
One of the intricacies that annoyed me the most was defining dependencies using build settings and build phases. In particular, having to modify a bunch of projects every time I added a new transitive dynamic framework. For that reason, one of the features that stand out from Tuist is its concise and easy API for defining dependencies. The tool translates my intent (I want A to depend on B) into build settings and phases.
Having worked with Rails and Ruby at Shopify showed me that working in projects (of any scale) can and must be enjoyable at any scale. They are a huge source of inspiration for me nowadays to build simple and conventional features into Tuist. I love observing the complexities in Xcode and wondering how can I make them simpler and approachable?
Every day I resist the temptation of porting features from Xcode, and rather imagine how I’d like to see myself doing my day-to-day tasks like renovating certificates and profiles, or scaffolding new features for my projects. I use what the community has built as an inspiration, but I make an effort to not be constrained by it. For instance, when I first suggested we should provide a standard CLI off conventional projects, there was a bit of pushback and “why not Fastlane” reaction? I think Fastlane is great, it’s just that we can leverage Tuist’s existing core pieces to provide a better experience at scale.
When I’m not adding code to Tuist, you can find me changing the design of the website, playing with GatsbyJS to build a great documentation experience, or sharing my excitement on Twitter for the new features that are coming to the platform.
I’m very passionate for this challenge, and I can’t wait to see how Tuist evolves to provide teams with more features to help them manage Xcode projects of any scale.