Dev Conversations #8: Pedro and Marek, from Tuist
Dev Conversations is a monthly series where Swift Toolkit features members of Swift work groups, content creators, and people who contribute to the Swift community, focused on tooling, developer experience and Server Side Swift.
In these talks, we discuss open source projects, tips for professional growth, and many other valuable insights and perspectives from other developers.
Back in 2017, Pedro Piñera was working at SoundCloud in the iOS Platform team. Their codebase was a mix of Swift and Objective-C, and developers faced difficulties when dealing with linking, build phases, build settings, and other complexities. Additionally, they would have Git conflicts in the Xcode project file.
That’s when Pedro decided to create a tool that would solve Xcode’s complexity by using project generation, which would abstract Xcode’s intricacies, instead of creating a new build system. With that, Tuist was born.
As Tuist’s users come from iOS and macOS development background, choosing Swift was a no-brainer, to encourage contributions from anyone using it. The tool was well received, the project became more popular, and the community around it grew over the years. One of the contributors, Marek Fořt, added support for SPM dependencies. Later on, he became part of the core team.
Facing the challenges of maintaining an open source project, Pedro and Marek decided to establish a company around Tuist. Their objective: to guarantee a sustainable future for the project and develop a better product.
In this episode, Pedro and Marek share the journey of Tuist since its inception, and discuss the challenges of scaling an open source project: what starts as a pet project can easily burn you out. They also explore some of the contributions they are able to provide to the Swift community, by extracting battle-tested parts of Tuist into reusable packages. Finally, they share the vision for the future of Tuist, by making it become more than a CLI tool. A broader ecosystem, with a server component and automation blocks, with the goal of helping developers in their workflows of creating software, testing it, sharing with others.
You can also find the written interview and the podcast links after the video in case you prefer reading or listening, and the relevant links at the end of this page.
Also available in your favorite podcast player 
Swift Toolkit
Hello Pedro, hey Marek! How are you both doing?
Pedro
Hello, it's good to be here, to be invited to the show.
Marek
All good, thanks for having us.
Swift Toolkit
Of course, Tuist was one of the most important tools that I started working with, when I was working in iOS infrastructure. It's been a source of inspiration for a few years. So it's a pleasure to have you guys here.
Pedro
I think at the time it was not that common to write CLIs in Swift. It was very common in other ecosystems. So as soon as we saw the Swift argument parser, we couldn't, and we felt the pain points of Xcode projects and Xcode. It felt like we had to do something about it. So it's great that when we look back, everything that has happened since.
Swift Toolkit
For sure! For people who don't what Tuist is, maybe you can start by telling the history and how it all started.
Pedro
I was working at SoundCloud, in 2017, and we had a modular codebase mixing Objective-C and Swift. The main pain point was maintaining modularity - dealing with linking, frameworks, libraries, build phases, and settings. With small projects it was manageable, but as the graph grew larger, even small changes could break the entire build. Plus, we had frequent git conflicts due to Xcode's monolithic format.
We took inspiration from CocoaPods' approach. Instead of trying to change Xcode's format or build system, which would force developers away from Xcode, we focused on project generation. This allowed us to address the complexity of modularization and git conflicts while keeping developers in their familiar environment.
We built Tuist as a CLI tool and chose Swift as the implementation language. This was a strategic decision to encourage contributions from the iOS/macOS developer community, rather than using languages like Ruby or JavaScript. Looking back, Swift was definitely the right choice for the project.
Swift Toolkit
Yes, and you had to write XcodeProj from zero. Cocoapods had their own Ruby Gem, XcodeProj, then you had to implement one in Swift to allow Tuist to use it.
Pedro
We needed to create our own XcodeProj implementation in Swift. While the basic writing functionality wasn't too complex, we ended up building a complete tool for reading, updating, and writing projects. A key requirement was ensuring minimal diffs when writing back modified projects.
The development process involved studying CocoaPods' XcodeProj, reverse engineering Xcode's pbxproj format, and lots of trial and error - making changes in Xcode's UI and analyzing the resulting changes in Git. After building this foundation and Tuist itself, Marek joined as a contributor. So maybe Marek, you want to share more about what happened since.
Marek
I joined Tuist when I was working on white-labeling apps. Tuist caught my attention because it made it easy to define the same app structure multiple times with different configurations - something that was perfect for white-labeling.
At that time, Xcode had just added Swift Package Manager support, but Tuist didn't support it yet. I found an issue about this and offered to help. Pedro welcomed the contribution and guided me through the process. After implementing SPM support, I stayed involved with the project.
This approach of guiding contributors became part of our philosophy - to help people to solve them themselves by giving them pointers. That's also why picking Swift was a great idea because it makes it much more approachable for the rest of the community to contribute. Choosing Swift as Tuist's language was crucial for this - since most iOS developers already know Swift, they can focus on understanding the codebase without having to learn a new programming language simultaneously.
Swift Toolkit
That makes sense. I remember I contributed a bit in the past and I'm sure that, in the same way that for me it was easier, I'm sure that many people in the community, they can contribute as well. I think that the numbers prove Swift was the right choice.
And what do you see as the challenges that you faced in this journey? We are now in Tuist 4, and you created Tuist around 2018.
Pedro
Yeah, we've gone through several major versions. We practiced dog-fooding by using the tool ourselves, which helped us feel the pain points we needed to solve. Sometimes these aligned with what users reported, other times they were different, but this approach helped the tool grow both in features and popularity.
The biggest challenge we faced is sustainability. This is a common theme you hear open source developers talking about - suddenly this thing that was your joy, something you did in your spare time, starts taking up a lot of your time. We started experiencing this and knew we had to do something about it.
With open source projects, I see three typical paths. First, you build something that remains a small toy project that no one knows about - you just tinker with it whenever you have time. Second, it becomes popular and people start using it. Then you reach a point where you need to find a way to make yourself psychologically stable to handle everything.
You have to deal with support requests, feature requests, issues - processing everything while maintaining your full-time job and managing the project on the side without burning out. It's very tricky because when you have your full-time job and all this open source work on top, it's unsustainable. We've seen many projects where the maintainer burns out and the project dies.
Swift Toolkit
Yeah, it easily becomes a burden with the overflow of notifications and people opening issues.
Pedro
Exactly. Some open source projects can reach a "done" state, like Mise - where they're mostly complete and only need minor improvements. But Tuist is different, because Xcode itself keeps evolving, adding new features, and users keep demanding more. We can never really say we're done because we need to keep up with these changes.
A lot of our time isn't even spent on adding features or fixing bugs in Tuist, but rather helping people with their Xcode project questions and needs. This wasn't sustainable in Tuist's original form. Some projects face this situation and just have to say "this is what it is" and then stagnate, with no further development.
Swift Toolkit
Before establishing a company, how did you handle all this?
Pedro
Initially, we had the privilege of having extra time to devote to the project - it's something that some people have at certain phases in their lives. Both Marek and I had that freedom, which allowed us to devote that extra time to the project. But as life goes on and priorities change, and the project was demanding more and more energy that we didn't have, we reached an inflection point where we knew we needed to do something about it.
Swift Toolkit
But at the same time, you created a group of core maintainers, right? So I assume this helped a ton.
Pedro
Having core maintainers helps distribute the load across multiple people instead of just one person steering the project. But it's not enough on its own, because maintaining a group also requires time and energy. You can't make yourself completely dispensable. While it helped, we still needed to invest significant time into the project to keep up with user demands and requirements.
Marek
There's only so much you can distribute across the core group, and their time availability changes over time. As you get more users, you still need PRs to be reviewed by just a couple of people - you can't just have random people reviewing and accepting, or the code quality suffers.
You need a strong, active group to properly review PRs and steer the project. But as the project grows more popular, you can't just keep adding people to the core group. You need a dedicated set of people who are consistently active, and that's something that doesn't usually work well in open source.
We could have continued as a purely open source project in our free time, but any of us could have dropped out at any point. Someone might have picked up the slack, but it's really tricky to maintain the quality of contributions and keep the project going long-term. That's where things usually get complicated.
Swift Toolkit
And what other learnings did you have since starting Tuist? Especially in the iOS world, macOS, and we had new platforms launched since then. What are some interesting bits you can share?
Pedro
Beyond the sustainability challenges, we found that Apple's tooling isn't really that extensible, which forced us to get creative in solving problems. We started with project generation, but we ended up solving many other challenges that required similar creative approaches.
For example, when we introduced binary caching, we had to be creative with Apple's foundations. We combined project generation with XCFrameworks to transform the dependency graph into something that compiles faster by skipping compilation steps. Marek worked on the Tuist Registry, mirroring Swift Package Index for faster resolution and more efficient caching, because the directory that you get in your system is more lightweight.
We built on top of interfaces that Apple provided, though I'm not sure if they designed them with these use cases in mind. What we'd really love to see is more extensible tools. We get that you can't cater to every company's needs with so many developers out there, but if you make your tools extensible enough, you enable people to solve their own problems.
The current extensibility options are really limiting - build phase scripts aren't enough, and the SPM build tool plugin system isn't really enough either. It's frustrating because we'd prefer to extend using proper APIs instead of having to hack the tools, but that's what we often find ourselves doing.
Marek
Yeah, I would add that when things aren't extensible but you really want to achieve something like project generation or binary caching, you end up sort of forking the ecosystem. And that's super, super costly because once you deviate from what everyone else is doing, you get into this cycle where every time Apple updates something, you have to update your abstraction on top of that.
That's where a lot of our maintenance work comes from. Take our custom Swift package integration - we had to do it this way to turn packages into XCFrameworks for binary caching. It's probably more costly to maintain than Xcode itself because of how SPM integrates with Xcode. There are lots of convenience features and undeclared behaviors that require reverse engineering. And since SPM is in a more fluid state than Xcode right now, it's become a really big chunk of our maintenance work.
We did fork the ecosystem for good reasons, but we'd be happy to align back with it if Apple makes SPM and its Xcode integration more extensible. We'd much prefer that over maintaining our fork, because these forks are super, super expensive to maintain.
Swift Toolkit
And another issue is that they're not always clear about where it's going, right? Although it's open source, doesn't behave so much as an open source project...
Pedro
You see hints of what's happening here and there with Apple's development. Like when they announced Swift Build a month ago - everyone got excited but wasn't sure what it meant. Now we see it's about having a unified build system across SPM and tools, that is positive. They're also working on caching at a lower level, taking ideas from other ecosystems instead of us having to reinvent it.
Strategically, we're now watching what Apple is doing more closely. While sometimes we need to fork the ecosystem - like we did with project generation - we're looking for opportunities to plug into their projects and add value where we can. Eventually, caching will be solved at the build system level, but it'll take years.
There are several steps needed: first, everything needs to be explicit - that's why they're pushing everyone toward explicit modules and I recommend everyone to use them. Second, they're evolving the build system to include caching. But that would require a server component, which is where we're thinking about how we can bring value. How can we build the best server for this?
Ideally, we want Tuist to become something you plug into an extensible toolchain, filling the gaps that Apple isn't addressing, rather than having to fork everything. Sometimes forks are necessary to show what's possible, to demonstrate to Apple and the industry what could be done if we had the right tools. Eventually, these innovations tend to happen at lower levels.
We've already seen this happen with Git conflicts - they're less frequent now with synchronized groups in Xcode 16. The complexity of linking and modularization is still a pain point, which is why many people use SPM as a project manager. Maybe they'll solve it with something other than build phases, or maybe SPM becomes the solution. We're keeping an eye on all of this and thinking about what it means for Tuist as both a tool and a business.
Swift Toolkit
That's really great! And changing a bit subjects, you mentioned some of the tools that you had to create. You've been also maintaining other packages focused on tooling.
How do you see tooling nowadays compared to where it was a few years ago?
Pedro
I mean, you can clearly see there's a strong focus on Swift being used in Apple platforms - iOS, macOS, building apps. There's more happening now with Swift being used in other areas like embedded platforms, CLIs, and server-side. But if you look at the community building packages and filling gaps, we're still far behind other ecosystems.
We're trying to contribute what we can, especially for CLIs. Apple gave us some great tools like Swift Argument Parser, which is amazing. They had Swift tools support at some point - with really useful things like AbsolutePath and RelativePath - but they deprecated it for some reason. We'd love to see them fill other gaps too, like running child processes. Sure, you have the process utility from Foundation, but if you compare those APIs to other languages, they're so, so old and need updating.
Swift Toolkit
Speaking of running child processes, we covered a few months ago Command, which is very useful, it has support for async await and handles possible race conditions.
Pedro
Exactly. We're always looking for opportunities to fill gaps in the ecosystem. Right now, we're working on a design system called Noora. You know, we often focus too much on CLI business logic, but they can have interfaces too. Even though you're limited to text, colors, spaces, and a few other terminal features, you can still design great experiences.
So we're thinking about how to design Tuist's output to be more useful, and how to package this in a way that anyone can use it for their own CLIs. We're really excited about this because we see ourselves as an open source company - we try to do as much as we can in the open.
Contributing packages to the community is how you move the ecosystem forward. You lift up the things that developers need, so instead of everyone having to think about CLI UI, they can just plug in a package and use it. That's why we're building a company - to do more of this. If you look at the packages we've been releasing lately, it really reflects this strategy.
Swift Toolkit
It's really great to have this option that you also use components in Tuist, and whenever you see something is ready to be packaged, then you just ship it so everyone can use it.
Pedro
I would add that we have two approaches to building tools. Sometimes we have a clear idea of something we want to build from scratch, like the design system. Other times, we notice that something we built inside Tuist could be really useful for the community as a standalone tool, so we extract it. It's amazing to see what happens when you take these internal tools and make them available.
The key is not just making it open source - it's about properly packaging it so others can easily use it in their projects. Take XcodeGraph for example - we had this internal tool for in-memory representation of project graphs. When we extracted it, we did it properly with backward compatibility, a proper release process, changelogs, release notes - everything you'd expect from a well-maintained package.
And then amazing things happen - like this developer Andy who came along and built an interactive graph visualizer in the browser using our package. That led to even more ideas, like building tools to convert Xcode projects into this standard in-memory representation. Suddenly you have this common data structure that everyone can build upon.
That allows to build tools on top of it. The graph visualizer is one of them, but you can implement link rules. You can implement all sorts of things. This is all independent from Tuist (although Tuist uses it internally), and we extracted it so that now it becomes something useful for the community.
Swift Toolkit
Another PR that was merged recently, allow to use XcodeGraph even in general generic old school Xcode projects, without the project generation part.
Marek
Yeah, this goes back to us going back and aligning with the ecosystem. So now we can use some of the Tuist features don't require you to generate your projects. Now some of the features like Tuist graph are also useful for projects that are of using standard Xcode projects or even Xcode project with local packages for managing your projects.
Again, that was a completely open source contribution from a person who was just very excited about the idea. And that wouldn't have happened if we didn't put that as a sort of commodity, and told people this is now something that you can use, modify and contribute back to.
Swift Toolkit
That's very nice! And I was going to ask about future plans of Tuist and where are you headed. And I think that this already answers a little bit already.
You are trying to expand to the broader iOS, Xcode, macOS community that doesn't use Tuist already, right? What else is in sight for you?
Pedro
So we're really focusing on solving productivity problems. We want to help developers do their best work faster, but in a way that doesn't require massive changes to their projects and tools. Tools like XcodeGraph are helping enable this vision by making these capabilities accessible to everyone. But you know, with more users comes more responsibility - and that brings us back to the sustainability challenge.
That's why we're thinking carefully about where we can bring value and how to monetize it - because that's what makes a business sustainable. We'll keep building client-side tools, packages, and libraries that anyone can use to build their own tools or services. That's how we make the tooling ecosystem accessible. But we're also going to bring value through a server component, where we can capture value by offering it as a paid service.
A server gives us three key pieces: a database for storing information over time, an API that can communicate with other servers and handle webhooks, and a background job system. With these three elements in place, we can solve problems in ways that wouldn't be possible with just client-side tools.
We already have all these client-side tools and deep understanding of Xcode projects, builds, and test results. By pushing this to a server, we can leverage that information to build tools that really help with productivity. Think about it - we're building a toolchain similar to what other ecosystems have, like Vercel and Netlify for web, or Expo for React Native.
The goal is to create an integrated toolchain where you just open Xcode and build your app, and everything else is taken care of - analytics, build optimization, test optimization, all of it. You focus on what matters - building the best apps you can - and we make sure you can do that job efficiently. That's how we see the future of the platform.
Swift Toolkit
Very nice. And then each person, each developer can bring the pieces they want and build with these blocks you provide.
Pedro
Exactly, we'll keep putting these commodities out there so people can build their own tools independently from Tuist. It's actually pretty similar to Docker's model - they started as a CLI and developed BuildKit, their virtualization technology. It's a great example of what we're trying to do.
When Docker extracted BuildKit as a commodity, anyone could use it to build their own virtualization CLI. But as their user base grew, they needed a business model, so they added a server component. Docker evolved from just a CLI into a complete product that combines a registry, images, and the CLI working together.
That's exactly what we're doing with Tuist - it's not just a CLI anymore, it's becoming a combination of server and CLI components. The CLI is just one way to interact with the server, and we've got the web dashboard too. We might even build native apps in the future for different use cases.
As we build all of this, we keep looking for opportunities to extract useful commodities and make them open source. We believe everyone benefits from this approach - us and the whole ecosystem. That's really our philosophy when it comes to open source.
Swift Toolkit
I'm looking forward to see this becoming a reality and I'm really, really excited to see the community making use of it!
Thank you both for your insights. I'm really proud of having taken a little part on on the history of Tuist, and seeing how much it grew and and where it's headed to. I wish you both a lot of success and good luck in the continuation of this journey.
I'll leave the links to the relevant resources here in the notes. It was a pleasure talking to you!
Pedro
Thank you Natan!
Marek
Sure, and thanks for inviting us!
