Today an idea popped in my mind, and I’d like to share with all of you to get your thoughts on it. Part of why frameworks like Rails are able provide very streamlined and user-friendly workflows is because they are opinionated about the structure of the projects. Although some developers might see that as a limitation, the reality is that developers can have more focus because they don’t have to spend time debating where files should be placed and named.
Why am I bringing this up? Tuist is weakly opinionated. We give users an API to describe their projects. In some areas, the API simplifies concepts from the underlying layer, like defining dependencies. This approach eases the adoption of Tuist, but it complicates offering more workflows to developers other than the so-used
tuist generate. I implemented a first iteration of
tuist cache and when tried to use it in large codebases, I realized that we can’t ensure it works reliably with all different project scenarios: with CocoaPods dependencies, without them, with Swift Packages, with hacky build phases, with some implicit linking through build settings. We could attempt to understand that complexity, but we’d never be able to handle all the scenarios gracefully. The consequence of that are certain features not working as expected because they make a lot of assumptions about the users’ projects. Similarly, reliable selective builds and tests would be hard without fully owning the definition of schemes. If we use the schemes used by the user, it might happen that they are not well set up for what the feature needs.
I’d like Tuist to provide those workflows leveraging conventions, but I don’t think nudging current users towards something like this is a good idea. One idea that I had was adding a new manifest type,
App.swift, to define conventional apps. The generation process would know how to turn it into workspaces and projects. Then features like build or cache could safely assume that certain conventions are met. The problem though is that users might find themselves trying to use tuist build and realizing that it doesn’t work because their projects need to be conventional. That’s a bad experience for the user and I’d avoid it.
What if Tuist remains as a project generation tool and we build a companion tool that leverages Tuist’s building blocks to provide a more conventional way for building apps? The opportunities for optimizations and streamlined workflows are huge and worth exploring.
This is what I had in mind for the API
I also did a brain-dump on this Twitter thread