An opinionated version of Tuist

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

1 Like

I think it’s useful. However, most people are migrating to Tuist from existing apps, so it is likely less useful in those cases. It might be easier to provide some templates for how to set up the building blocks of all the modules to enable getting people on that path.

From what I can gather, it seems to be that if you’ve got a situation where everyting is expressible by .project types things can stay relatively flexible, but that external package manager situation is where things might need to be more opinionated.

I think it’s useful. However, most people are migrating to Tuist from existing apps, so it is likely less useful in those cases. It might be easier to provide some templates for how to set up the building blocks of all the modules to enable getting people on that path.

Right. We know how painful the adoption of Tuist can be, and nudging them to some kind of pre-defined structure would be painful for some projects.

I slept a bit over the idea and I think we can figure out the way to limit bad practices and encourage good ones without having to build a new tool or introduce radical changes in Tuist.