The role of flexibility in scaling up Xcode projects
I often wonder why Apple continues to build features that are closed into Xcode, for example Swift Package Manager’s integration. While some developers might see that as something positive, because that means it can be seamlessly integrated into Xcode’s UI and workflows, I see it as a complication for scaling up Xcode projects. Let me unfold this last thought in this post.
You can’t build a tool that satifies every team’s needs. You can’t design Xcode to work for the tiny startup that is building a simple app, as well as for a company like Facebook that has a complex project with many inter-dependent targets. Apple optimizes for one type of app, the one that is the most common across all the projects: a mono-target app that might have extensions and support for multiple platforms. In that setup, Xcode works fine. You create your project using Xcode’s menus, add a new target when needed to extend your app, and add third-party dependencies through the Swift Package Manager integration. Xcode, the project format, its build system, Swift, and all the surrounding tools are designed for that. There’s nothing wrong with that, except that those developers that need more are left out of the equation. Their projects take a long time to compile, tiny changes cause the build to break, and Xcode is not as responsive as it used to be. Companies like Uber have suffered a lot from this. Others have adopted Bazel as a build system to escape the problem, and need dedicated resources to keep it working with every Xcode/Swift update.
Because Apple doesn’t open those APIs, Tuist is taking the role of opening them for developers.
We are doing that by leveraging Xcode project generation.
We abstract the
project.pbxproj format with a more declarative format that can be extended easily.
Developers love that,
and the fact that Apple doesn’t change their mindset is positive for Tuist because they create a room for the project to thrive.