Troubleshoot the dependency problems that bite Tuist users most — 'No such module' after generation, missing Swift packages, and broken module links — with a clear fix sequence.
A "No such module" error at build time means Xcode cannot find a module you imported. With Tuist, the cause is almost always that the dependency was not declared or not resolved before generation.
Remember the model: Xcode only knows about what your manifests describe. If a target imports a module it does not declare as a dependency, the generated project will not link it.
External Swift packages add another layer — they must be fetched and integrated before the generated project can reference them.
The fixes below cover both local module dependencies and external package dependencies, in the order worth checking.
For internal modules, confirm that the importing target lists the imported module in its dependencies. This is the single most common oversight.
It is easy to add an `import MyFeature` in code but forget to add the corresponding dependency entry in `Project.swift`. Xcode then has no link, and the module is not found.
Open the target's definition, add the missing dependency, and re-run `tuist generate`. The import should now resolve.
Because dependencies are explicit in Tuist, the fix is explicit too — code the edge into the manifest.
If the missing module comes from an external Swift package, it must be fetched and integrated. Tuist provides `tuist install` for resolving declared external dependencies.
Confirm the package is declared in the location your Tuist version expects for external dependencies, then run `tuist install` before `tuist generate`.
Skipping the install step is a frequent cause of unresolved external modules, because generation alone does not fetch remote packages.
Make `tuist install` a standard step in your onboarding and CI so packages are always resolved before generation.
Any time you add, remove, or rename a dependency, you must regenerate. The currently open Xcode project reflects the last generation, not your latest manifest edit.
Developers sometimes edit a manifest, then wonder why Xcode still cannot see the module — the project simply has not been regenerated yet.
After editing dependencies, close or ignore the stale project, run `tuist install` if external packages changed, then `tuist generate`.
Building this reflex prevents a large share of phantom dependency errors.
Sometimes the problem is structural. A module that everything expects to exist may not actually be linked into the path that needs it, or a dependency cycle is breaking resolution.
Use Tuist's graph visualization to inspect how modules connect. Look for the missing edge that should carry the module you cannot import.
If you find a cycle, refactor to make the graph acyclic — for example, extract shared code both modules need into a lower-level module they can both depend on.
Seeing the graph often makes an invisible linking problem obvious at a glance.
Mismatched product types can cause link-time surprises. How a module is built — for example as a static or dynamic product — affects how it must be linked and embedded.
Confirm each module's product type matches how it is consumed, and that resources and embedded frameworks are configured as your app expects.
Inconsistent linking setups can lead to modules that compile but fail to load, or symbols that go missing at build time.
When a dependency is declared and resolved yet still misbehaves, product type and linking configuration are the next place to look.
Swift module names must match exactly in your import statements and your manifest, and small inconsistencies produce confusing failures.
A module named `CoreKit` will not resolve from an `import Corekit`, and a target whose product name differs from what you import can leave Xcode looking for something that does not exist.
Confirm that the name you import matches the module's actual product name, not just its folder or scheme name. These can legitimately differ, which is a common source of confusion.
When the dependency is clearly declared but still not found, re-read the import line and the target definition side by side. A single character or a stray capitalization is often the whole problem.
Stale state can cause dependency errors that persist even after you fix the manifest. A clean pass clears these.
Delete the generated project and workspace, clear Tuist caches per your version's documentation, and remove any resolved-package state that has gone stale.
Then run `tuist install` followed by `tuist generate`, and let Xcode resolve fresh.
Starting clean rules out the frustrating case where your fix is correct but an old artifact is masking it.
If a specific external package still fails, verify the package itself supports your platform and deployment target. Not every package supports every Apple platform.
Check the package's own documentation and confirm the version you are pulling is compatible with your Tuist and Xcode versions.
Reproduce with a minimal manifest that pulls only the problematic dependency. Isolating it distinguishes a project-specific misconfiguration from an upstream compatibility issue.
Finally, keep scope in mind: resolving these errors gets your project to build, but signing and App Store submission still go through Xcode and the Apple Developer Program.
Most 'No such module' errors fall to a short, ordered set of checks, so run these before diving deeper.
First, confirm the importing target actually declares the module as a dependency in its manifest, and that you regenerated afterward. A declared-but-not-regenerated dependency is the single most common trap.
Second, if the module is an external Swift package, make sure you ran `tuist install` before `tuist generate`, since generation alone does not fetch remote packages.
Third, verify the import name exactly matches the module's product name, and use the graph visualization to confirm the linking edge you expect actually exists.
If all of that checks out and the error persists, do a clean pass: delete the generated project, clear caches and stale package state, reinstall, and regenerate. That sequence resolves nearly every case and cleanly separates a real misconfiguration from stale artifacts masking a fix you already made.
Over time, folding these checks into habit pays off more than any single fix. Declaring dependencies as you write imports, regenerating immediately, and running `tuist install` whenever packages change turns most 'No such module' errors into something you prevent rather than debug, so they stop stealing time from actual feature work.
You likely imported the module in code but did not declare it as a dependency in the manifest, or you have not regenerated. Add the dependency in Project.swift and run tuist generate.
Yes. External packages must be fetched and integrated with tuist install before tuist generate, since generation alone does not resolve remote dependencies.
Use Tuist's dependency graph visualization. It shows how modules connect and makes a missing edge or an unexpected cycle easy to spot.
Yes. Cycles break clean resolution. Refactor by extracting shared code into a lower-level module that both dependents can depend on, keeping the graph acyclic.