'No such module' and 'missing package product' are among the most common Swift Package Manager errors. This guide pinpoints why they happen and walks through the exact fixes so your imports compile again.
'No such module' and 'missing package product' are closely related and often appear together, so it helps to understand both at once.
'No such module' is a compiler error. It means your Swift code tried to import a module the compiler cannot find at build time.
'Missing package product' is a resolution or linking error. It means a target references a product that SPM cannot locate in the package graph.
Both usually trace back to the same root cause: a product exists in the package but is not correctly attached to the target that needs it, or the package failed to integrate fully.
The good news is that these errors are almost always configuration issues rather than bugs in your code, which means they are fixable with a predictable sequence of checks.
The most frequent cause is simply that the library product is not linked to the target where you import it. Start here.
Select your project in the Project Navigator, then select the specific target that contains the failing import. Open its General tab.
Under Frameworks, Libraries, and Embedded Content, confirm the package's library product is listed. If it is missing, click the plus button and add it.
If your app has multiple targets, such as the main app plus a widget or app extension, each target that imports the module needs the product added separately. Forgetting the second target is a classic mistake.
After adding the product, build again. In many cases this single fix clears both the missing product and the no-such-module errors at once.
Sometimes the product is linked correctly, but the name you import does not match the module the package actually exposes.
The import name corresponds to the library product or target name defined in the package's Package.swift, which is not always identical to the repository name.
Open the package's manifest or its documentation and find the exact product name. Then make sure your import statement uses that exact spelling, including capitalization.
Swift module names are case-sensitive, so a lowercase letter where the package uses uppercase will fail to resolve.
If the package exposes multiple products, confirm you are importing the specific one that contains the type you are using. Correcting a mismatched or misspelled import often resolves a stubborn no-such-module error immediately.
If the product is attached and named correctly, the package may not have finished integrating. A forced re-resolution frequently helps.
Choose File then Packages then Resolve Package Versions to ensure SPM has fully fetched and integrated the dependency.
If that does not work, reset the package caches with File then Packages then Reset Package Caches, then resolve again.
Follow up by cleaning the build folder with Shift plus Command plus K, which clears stale build products that may reference an old, incomplete integration.
Then build the project fresh. Combining a clean resolution with a clean build folder addresses cases where the package was added but Xcode's build state never caught up, which produces phantom missing-module errors.
A subtle cause is a platform mismatch between the package and your target. If the package does not support your platform or deployment target, its product may not be available.
Inspect the package's manifest for a platforms declaration. If it requires a newer minimum iOS version than your app targets, the product can fail to link.
Align your app's deployment target with the package's requirement, or choose a package version that supports your minimum OS.
Similarly, ensure you are building for a platform the package supports. A package built only for iOS will not provide a module when you build a macOS target.
Resolving the compatibility mismatch, either by adjusting your deployment target or picking an appropriate package version, restores the missing product on the platforms that actually support it.
When the error appears after pulling changes from teammates, suspect a bad Package.resolved or corrupted project state.
Check Package.resolved for merge conflict markers or inconsistent entries. A conflicted resolved file can cause the graph to be built incorrectly, dropping products.
If you find problems, delete Package.resolved and let SPM regenerate it, then resolve package versions and rebuild.
Also inspect the project file for merge conflicts that may have removed the product's link reference during a Git merge. Restoring the link in the target's General tab fixes this.
Deleting derived data for the project provides a final clean slate if corrupted intermediate state is suspected. After these steps, the package graph should rebuild cleanly and the module should resolve.
Occasionally the product genuinely does not exist under the name you expect, especially after upgrading a dependency across a major version.
Libraries sometimes rename or split their products between major releases. A product that existed in an older version may have been renamed or removed.
Open the package repository at the exact version you resolved and read its Package.swift and changelog. Confirm the product name you rely on still exists in that version.
If it was renamed, update your import and your target's linked product to the new name. If it was removed, you may need to add a replacement product or adjust your usage.
This check is easy to overlook because the error looks like a configuration bug, when in fact the package's public shape changed underneath you.
A little discipline keeps these errors uncommon. When you add a package, always verify in the General tab that its product is linked to every target that imports it.
Read a dependency's release notes before accepting a major-version update, since renamed products are a common breaking change.
Commit a clean Package.resolved and resolve conflicts in it deliberately, so teammates inherit a consistent, working graph.
Keep your deployment target and your dependencies' platform requirements in sync to avoid platform-driven missing products.
And remember the scope of the tool: SPM wires modules into your native build, but it does not build or ship your app on its own. Xcode and the Apple Developer Program remain required for a real native app and any App Store release, so fixing these import errors simply unblocks the rest of that native workflow.
Most often the library product is not attached to the target you are importing it into. Add it in the target's General tab under Frameworks, Libraries, and Embedded Content, then rebuild.
No. The import name matches the product or target name defined in Package.swift, which can differ from the repo name. Check the manifest for the exact, case-sensitive name.
Each target needs the product linked separately. Add the package product to the widget or extension target as well, not just the main app.
Yes. Libraries sometimes rename or remove products between major versions. Read the changelog and update your import and linked product to the new name.
It can, especially when stale build state references an old integration. Reset package caches, resolve versions, clean the build folder, then rebuild.