Using Tuist Generated Projects
Quick Start
Generate workspace without opening Xcode
tuist generate --no-open
Build a scheme with xcodebuild
xcodebuild build -workspace App.xcworkspace -scheme App
Run tests with xcodebuild
xcodebuild test -workspace App.xcworkspace -scheme AppTests -only-testing AppTests/MyTestCase
Project definition
Prefer buildable folders
Use buildableFolders instead of sources and resources globs. Buildable folders stay synchronized with the file system, so adding or removing files does not require regeneration.
let target = Target( name: "App", buildableFolders: [ "App/Sources", "App/Resources", ] )
Tag targets for focus
Use target tags to group areas of the project, for example:
-
tag:team:*
-
tag:feature:*
-
tag:layer:*
These tags make it easier to scope generation and testing later.
Example target metadata with tags:
let target = Target( name: "PaymentsUI", metadata: .metadata(tags: [ "tag:team:commerce", "tag:feature:payments", "tag:layer:ui", ]) )
When working on a focused area, generate only what you need:
tuist generate tag:feature:payments tuist generate PaymentsUI PaymentsTests
Align build configurations
Keep build configurations aligned between the project and external dependencies. Use PackageSettings(settings: .settings(configurations: [])) to mirror project configurations; mismatches emit warnings.
Workflows
Generate intentionally
-
Use tuist generate --no-open in automation and scripts to avoid launching Xcode.
-
Regenerate when any manifest changes (or the dependency graph changes).
-
If generation fails due to missing products, run tuist install to resolve dependencies and retry.
Build with xcodebuild
Use xcodebuild build against the generated workspace and scheme.
xcodebuild build
-workspace App.xcworkspace
-scheme App
-destination "generic/platform=iOS Simulator"
Test with xcodebuild
Use xcodebuild test for running tests locally. Prefer it over tuist test because tuist test regenerates the project on each invocation, which slows down iteration.
To optimize test run time:
-
Use --only-testing to run only the specific test suite or test case you are working on, instead of the full target.
-
Pick the scheme with the fewest compilation targets that still includes the test target you need. This minimizes build time before tests run.
Run a specific test suite
xcodebuild test
-workspace App.xcworkspace
-scheme AppTests
-only-testing AppTests/MyTestSuite
Run a single test case
xcodebuild test
-workspace App.xcworkspace
-scheme AppTests
-only-testing AppTests/MyTestSuite/testMyFunction
Guidelines
-
Keep buildableFolders paths aligned to the target's real file system layout.
-
Avoid overlapping buildableFolders with sources or resources globs in the same target.
-
Open Xcode manually when needed after running tuist generate --no-open .
Troubleshooting
Static side effects warnings: adjust product types deliberately. Use Target.product for local targets and PackageSettings(productTypes:) for external products. Making everything dynamic with .framework can compile and run, but it may hurt launch time. Prefer static products (static frameworks or libraries) when possible and when they do not introduce side effects.
Objective-C dependency crashes: add -ObjC or -force_load via OTHER_LDFLAGS on consuming targets as needed. Reference: https://docs.tuist.dev/en/guides/features/projects/dependencies#objectivec-dependencies .