One of the biggest stumbling blocks I have using tuist with new projects is the initial setup. This is especially challenging when experimenting with things like extensions which are less common and have more configuration in plists and supporting files. My current workflow is to create a new project from scratch in Xcode and manually convert what is generated there into Tuist.
Xcode ships a set of templates (as xctemplate directories) in $DEVELOPER_DIR/Library/Xcode/Templates/ as well as $DEVELOPER_DIR/Platforms/<platform>.platform/Developer/Library/Xcode/Templates/. These templates can reference each other and contain both template source files and code gen instructions internally, as well as build settings and other project configuration. The format is fairly straightforward and something we could reverse engineer to inform Tuist generation.
Benefits:
- Expanded library of starter projects usable via tuist.
- Up-to-date init with default configuration based on Xcode.
- No need to maintain independent tuist init template.
Risks:
- Another format to keep parity with.
- More code, more problems.
- Probably other things I haven’t thought of this morning.
If we didn’t want to go this full length, we could alternatively select a few of the templates that exist today and modify them to generate Tuist projects from within Xcode allowing engineers to File → New Project → Tuist Project. This could lower the barrier to entry by keeping with familiar UI engineers are used to.