You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During a sync meeting of the core group last week, we had an interesting discussion around Tuist and its scope of features which made me think a lot. To give some context, some people are inclined towards Tuist doing few things, but doing them really well. One of those things is project generation. Our graph-based project generation has proven to be more useful than alternatives like XcodeGen that move you from pbxproj’s domain to YAML to get rid of git conflicts.
I fully agree that we should make sure that our graph supports all the features that developers need and that project generation works really well and fast. However, there are many features that we built into Tuist that are intimately connected to our graph and project generation that improve the developer experience significantly. A good example of that is tuist build. One could argue that Tuist doesn’t need to expose that command because developers can simply run xcodebuild or use Fastlane’s Gym tool. Although that’s right, those tools will never be able to provide the developer experience we provide where the user doesn’t have to create and maintain an extra manifest file, Fastfile, or remember what arguments to pass to xcodebuild. It’s a subtle thing that at the end of the day makes a huge difference for teams and we can do that because Tuist has knowledge on your projects. If we compare this to Rails, it’d be the same as saying that rails db:setup because one could run the database setup commands manually and Rails could focus only on the building blocks to build an MVC web app. There’s beauty in having those utilities built-in.
Every new Tuist feature is part of a cohesive developer experience. Every command represents a standard workflow that developers can familiarize themselves with and use with any Tuist projects. We remove the cognitive load and indirection introduced by complex tooling stacks. That’s crucial when scaling up projects and I believe Tuist needs to play a role in reminding developers that scaling and complexity are not necessarily related, and more importantly, they don’t need a tooling team to make that happen.
I don't expect all the users to embrace Tuist's workflows. If a team only needs project generation, they can simply use that feature. Moreover, they can import TuistGenerator and build their own tool upon our generation logic as Bloomberg does. For those users that want to go beyond project generation and want Tuist to become their tooling team, we'll be there providing and optimizing workflows.
All of this comes with a caveat, if we provide many features, how do we make sure this doesn't translate into a maintenance burden from which we'll suffer. I think we need to be mindful when adding new features to the project. If there's a workflow that brings a lot of value to users and we can make it 10x better than what's out there, and it aligns with Tuist's story, we should do it. We should build it in a modular way, well-architected, and documented, such that other contributors and maintainers can improve it and fix issues easily in the future. If we make our features easy to contribute to, we can invite developers reporting bugs or ideas to contribute to the features themselves.
Long story short:
There's an opportunity for Tuist to be more than a project generation and provide developers with a cohesive developer experience. Those other features should always be opt-in.
We should be careful to not become another Fastlane. Unlike them, we should design standard workflows that teams can embrace.
To prevent the fatigue that might come from having to maintain many features, I'd make sure that we build them in a modular way and they are easy to contribute.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
During a sync meeting of the core group last week, we had an interesting discussion around Tuist and its scope of features which made me think a lot. To give some context, some people are inclined towards Tuist doing few things, but doing them really well. One of those things is project generation. Our graph-based project generation has proven to be more useful than alternatives like XcodeGen that move you from pbxproj’s domain to YAML to get rid of git conflicts.
I fully agree that we should make sure that our graph supports all the features that developers need and that project generation works really well and fast. However, there are many features that we built into Tuist that are intimately connected to our graph and project generation that improve the developer experience significantly. A good example of that is
tuist build
. One could argue that Tuist doesn’t need to expose that command because developers can simply runxcodebuild
or use Fastlane’s Gym tool. Although that’s right, those tools will never be able to provide the developer experience we provide where the user doesn’t have to create and maintain an extra manifest file,Fastfile
, or remember what arguments to pass toxcodebuild
. It’s a subtle thing that at the end of the day makes a huge difference for teams and we can do that because Tuist has knowledge on your projects. If we compare this to Rails, it’d be the same as saying thatrails db:setup
because one could run the database setup commands manually and Rails could focus only on the building blocks to build an MVC web app. There’s beauty in having those utilities built-in.Every new Tuist feature is part of a cohesive developer experience. Every command represents a standard workflow that developers can familiarize themselves with and use with any Tuist projects. We remove the cognitive load and indirection introduced by complex tooling stacks. That’s crucial when scaling up projects and I believe Tuist needs to play a role in reminding developers that scaling and complexity are not necessarily related, and more importantly, they don’t need a tooling team to make that happen.
I don't expect all the users to embrace Tuist's workflows. If a team only needs project generation, they can simply use that feature. Moreover, they can import
TuistGenerator
and build their own tool upon our generation logic as Bloomberg does. For those users that want to go beyond project generation and want Tuist to become their tooling team, we'll be there providing and optimizing workflows.All of this comes with a caveat, if we provide many features, how do we make sure this doesn't translate into a maintenance burden from which we'll suffer. I think we need to be mindful when adding new features to the project. If there's a workflow that brings a lot of value to users and we can make it 10x better than what's out there, and it aligns with Tuist's story, we should do it. We should build it in a modular way, well-architected, and documented, such that other contributors and maintainers can improve it and fix issues easily in the future. If we make our features easy to contribute to, we can invite developers reporting bugs or ideas to contribute to the features themselves.
Long story short:
Beta Was this translation helpful? Give feedback.
All reactions