I’ve been pondering this idea for a while so I decided to bring it up for further discussion with the community.
Xcode projects are the result of a combination of the following primitives: build settings and phases, targets, projects, and schemes. Having all those primitives allow teams to define any type of projects, but they also open the door for defining very complex configuration scenarios. Those complex scenarios are typically extended using
xcodebuild arguments when building or testing schemes on continuous integration.
Teams see this grade of flexibility and configurability as something great, but I see them as a door to introduce accidental complexity. Even if we made their maintenance easier in Tuist with the help of features like project description helpers, complexity can still happen.
Like we did with the definition of dependencies, where developers no longer have to hink about linking build settings and phases, I think we should provide an API that abstracts away the definition of schemes. I don’t know yet how that API should look, but it’s a path that I want us to consider.
Since developers are already using our Xcode-alike API,
Schemes, we should keep it, but we’d provide so much value and simplicity from the new API, that developers wouldn’t see a reason for maintaining a list of schemes themselves.
My motivation for going down this path is not just embracing simplicity, but giving us the control over the schemes to provide automation options that wouldn’t be possible with a static list of schemes. For instance, on CI we could generate a list of schemes to only build or test what needs to be built and tested based on the file changes. With a static list of schemes, we could still do that, but there’s the risk of our dynamic behavior conflicting with the static one, which might result in failing commands.
What are your thoughts on this?