Xcode “No such module”: inspect the target dependency
Determine whether a Swift package product or framework is resolved, linked, and available for the build destination.
The importing target cannot see a module for the current build. Check the exact import name, package resolution, target membership and linked product, then whether a binary dependency supports the selected platform and architecture.
Try these fixes in order
Check the first failing import and target
Read the Issue navigator for the file, target, configuration, and destination that fail. Confirm the import spelling matches the module or package product name; a repository name is not always the importable module name.
Confirm the dependency is in the project
Inspect Package Dependencies and the affected target’s linked frameworks or package products. Add the intended product to that target if missing. A different app or test target may already have it, which does not make it available everywhere.
Resolve package versions deliberately
Review version requirements and Package.resolved. Use Xcode’s package resolution action and inspect any changes to pinned versions. For CI, ensure the resolved file and private repository access are available to the build environment.
Check platform and binary support
If only a simulator or device build fails, verify the package’s platform minimum and whether a binary XCFramework contains the needed platform and architecture slice. Ask the vendor for a compatible artifact rather than forcing an unrelated architecture setting.
Interpret what you see
Only one target reports the import error
What it suggests: Dependencies are linked per target.
Next check: Inspect the package product under that target’s Frameworks and Libraries and add the correct product there.
Only simulator or device fails
What it suggests: A binary package may lack a matching platform and architecture slice.
Next check: Inspect its XCFramework contents and request a compatible vendor build if the slice is absent.
CI fails while local Xcode resolves it
What it suggests: The runner may lack Package.resolved or access to a private repository.
Next check: Compare the committed lockfile and repository credentials used by that runner.
Why this happens
- The product is not linked to the target that imports it.
- Resolution failed or the binary does not include the destination’s platform and architecture.
Still not working?
Do not treat deleting DerivedData as a substitute for checking target configuration. If source and dependency settings are correct but Xcode still reports stale diagnostics, perform a clean build and record the first real compiler issue.
Official sources
- Apple: add package dependencies to your app ↗
- Apple: identify binary dependencies ↗
- Apple: Swift packages in CI ↗
These steps are based on the linked documentation and general diagnostics. BugMedic has not independently tested every product and system configuration. Review commands before running them.