migrating-to-tuist-generated-projects
Skill35 starsChanged 8 months agoMITView on GitHub
Migrates existing Xcode projects to Tuist generated workspaces with build and run validation, external dependency mapping, and migration checklists. Use when adopting Tuist for an existing app or converting a hand-edited Xcode project to generated projects.
In this repository11 other files it gives its agents.
- analyze-selective-testingSkill
- compare-buildsSkill
- compare-bundlesSkill
- compare-cache-runsSkill
- compare-generationsSkill
- compare-gradle-buildsSkill
- compare-test-caseSkill
- compare-test-runsSkill
- debug-generated-projectSkill
- fix-flaky-testsSkill
- using-tuist-generated-projectsSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 5 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
Create Tuist.swift, Project.swift, and Tuist/Package.swift.
- Distinctive: line 40
Start by proving the current project builds and runs.
- Distinctive: line 57
Create the manifests and keep them minimal and close to the existing project.
- Very specific: line 63
Use .external for third-party dependencies to keep the graph consistent.
- Very specific: line 71
Use .folderReference for bundles like Settings.bundle.
- Very specific: line 72
If a resource bundle is missing, ensure the package target declares .process("Resources").
- Very specific: line 91
Missing SDK frameworks: add .sdk(name: ..., type: .framework).
- Very specific: line 92
SPM resource bundles: verify .process("Resources") and Bundle.module usage.
- Distinctive: line 93
File-system-synchronized groups: avoid over-excluding directories.
- Distinctive: line 95
Generated sources: ensure codegen outputs (SwiftGen/Sourcery) are part of the build.
- Distinctive: line 127
All targets and extensions build
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Migrating to Tuist Generated Projects
Quick Start
- Baseline build and run the app with xcodebuild.
- Inventory targets, build settings, and external dependencies.
- Create
Tuist.swift,Project.swift, andTuist/Package.swift. - Extract settings into
.xcconfigfiles and wire them inProject.swift. - Generate and build:
tuist generate --no-openthenxcodebuild build. - Fix build issues, regenerate, and validate runtime on a simulator.
Preflight Checklist
- Primary app scheme and any extension/test schemes
- Targets list (app, extensions, tests, helper tools)
- Deployment targets and bundle identifiers
- Info.plist locations and entitlements
- Custom build settings (per target and per configuration)
- External dependencies (SPM, XCFrameworks, local packages)
- Build scripts (SwiftGen, Sourcery, codegen)
- Runtime validation plan (simulator destination and launch command)
Outputs
Project.swiftandTuist.swiftTuist/Package.swiftfor external dependencies.xcconfigfiles (optional but recommended)- Build and runtime validation notes
- A short migration log of decisions and fixes
Migration Workflow
1. Baseline the project
Start by proving the current project builds and runs. Capture the command you use so the generated workspace can be validated the same way.
xcodebuild build \
-project App.xcodeproj \
-scheme App \
-configuration Debug \
-destination "generic/platform=iOS Simulator" \
-derivedDataPath DerivedDataBaseline2. Map targets and settings
List every target and its role. Extract build settings into .xcconfig files when they are large or shared across targets. Keep deployment targets and bundle identifiers identical to the original project to avoid runtime surprises.
3. Add Tuist manifests
Create the manifests and keep them minimal and close to the existing project.
Tuist.swift: enable generation options you need and keep them explicit.Project.swift: define targets, sources, resources, scripts, and dependencies.Tuist/Package.swift: list external dependencies and map product types.
Use .external for third-party dependencies to keep the graph consistent.
4. Handle sources and resources carefully
Be precise here. Small mistakes often cause large failures later.
.intentdefinitionfiles belong insources, notresources..xcstringsshould remain the primary localization source. Avoid double-including.stringsor.stringsdictfrom overlapping globs.- Use
.folderReferencefor bundles likeSettings.bundle. - If a resource bundle is missing, ensure the package target declares
.process("Resources").
5. Generate and build
tuist install
tuist generate --no-open
xcodebuild build \
-workspace App.xcworkspace \
-scheme App \
-configuration Debug \
-destination "generic/platform=iOS Simulator" \
-derivedDataPath DerivedDataTuist6. Resolve build issues iteratively
Common fixes you will likely need:
- Missing SDK frameworks: add
.sdk(name: ..., type: .framework). - SPM resource bundles: verify
.process("Resources")andBundle.moduleusage. - File-system-synchronized groups: avoid over-excluding directories; compare with the pbx if a type vanishes.
- Invalid bundle identifiers: override with
PackageSettingsor vendor a local package. - Generated sources: ensure codegen outputs (SwiftGen/Sourcery) are part of the build.
7. Validate runtime
A build is not enough; launch the app on a simulator.
xcrun simctl boot "iPhone 17 Pro"
xcrun simctl install booted DerivedDataTuist/Build/Products/Debug-iphonesimulator/App.app
xcrun simctl launch booted com.example.appCommon Failure Patterns
- Type not found: a source file or entire directory was excluded accidentally.
- Copy Bundle Resources errors: Swift files are being treated as resources; fix the resource globs.
- Localization conflicts:
.xcstringscolliding with.stringsglobs. - Undefined symbols: missing SDK frameworks or dependency products.
- Unrecognized selector at launch: ObjC categories in static frameworks were stripped. Add
-ObjCtoOTHER_LDFLAGSor-force_loadfor the library that defines the category. - Runtime crash on launch: mismatched bundle id, missing entitlements, or miswired resources.
Migration Notes to Capture
- What changed in
Project.swiftand why - Any exclusions or overrides (and the reason)
- Dependency patches or local vendoring
- The exact build and run commands used for validation
Done Checklist
- Generated workspace builds cleanly
- App launches on simulator without immediate crash
- All targets and extensions build
- Dependencies are wired through
.external - Settings match the original Xcode project
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

