How to Fix Swift “No Such Module” in Xcode

No such module 'ModuleName'

import Alamofire // No such module 'Alamofire'

What does “No such module” mean in Swift?

Swift imports external modules with the import statement.

import Foundation import Alamofire import MyFramework

During compilation, Swift must be able to locate the compiled module or the source dependency required to build it.

If the module is not part of the target’s dependency graph or cannot be found in the appropriate build paths, compilation stops with:

No such module 'MyFramework'

Common causes

1. The Swift Package was added, but its product was not added to the target

This is one of the most common causes.

Adding a package dependency to a project does not automatically make every product from that package available to every target.

The product that provides the module must be added to the target that imports it.

.target( name: "MyApp", dependencies: [ .product( name: "SomeLibrary", package: "SomePackage" ) ] )

2. The package name and module name are different

A Git repository name, Swift package name, library product name, target name, and importable module name do not necessarily match.

For example, the package may be called:

SomeNetworkingPackage

while its importable module is:

NetworkingCore

Check the dependency’s Package.swift and documentation.

3. The framework is not linked to the current target

A framework can exist in the Xcode project without being part of the target that is currently being compiled.

This is particularly common in projects with multiple app, test, or extension targets.

4. A CocoaPods project is opened with the .xcodeproj

CocoaPods normally integrates dependencies through an Xcode workspace.

If you open only the original .xcodeproj, the Pods project may not be available to the app target.

No such module 'Firebase' No such module 'Alamofire'

5. pod install has not been run

A cloned project may contain a Podfile but no locally installed Pods.

Until CocoaPods installs and integrates the dependencies, the module cannot be imported.

6. Swift Package dependency resolution failed

A package may appear in Xcode while dependency resolution is incomplete or broken.

Version conflicts, Git authentication errors, network problems, and Package.swift errors can prevent the package from being built.

7. The module does not support the current platform

A package may support macOS but not iOS, or a binary framework may support physical iOS devices but not iOS Simulator.

8. An XCFramework is missing the required slice

A binary dependency needs a compatible binary for the platform and architecture currently being built.

Typical slices include:

• iOS device arm64
• iOS Simulator arm64
• iOS Simulator x86_64

9. Framework Search Paths are incorrect

Manually integrated frameworks may not be located if FRAMEWORK_SEARCH_PATHS does not include the required directory.

10. Library Search Paths are incorrect

Static libraries may depend on LIBRARY_SEARCH_PATHS.

11. Header or module-map configuration is broken

Objective-C and C libraries exposed to Swift may rely on module maps or header search paths.

If those definitions are unavailable, Swift cannot import the module.

12. The app’s deployment target is lower than the dependency requires

A package that requires iOS 17 cannot necessarily be used by a target configured for an older minimum iOS version.

13. DerivedData or the module cache is stale

After dependency changes, Xcode may retain stale build or module information.

14. Debug and Release use different configurations

Debug may compile successfully while Archive fails because Release uses different search paths, xcconfig files, or dependencies.

15. A test target does not depend on the module

A module available to the application target is not automatically available to every Unit Test or UI Test target.

Typical situations where the error appears

• Immediately after adding a Swift Package
• Immediately after adding a CocoaPod
• After cloning a project from GitHub
• After changing Package.resolved
• After upgrading Xcode
• After changing the deployment target
• After manually adding a framework
• After moving from an Intel Mac to Apple Silicon
• After switching from a device build to a Simulator build
• After replacing a framework with an XCFramework
• When Debug works but Archive fails
• After adding a new test target

What to check first

1. Verify the module name

Start with the failing import:

import SomeLibrary

Confirm that SomeLibrary is actually the module name documented by the package or framework.

2. Verify the target dependency

Open the target in Xcode and inspect Frameworks, Libraries, and Embedded Content and Build Phases.

Make sure the product or framework is attached to the exact target that contains the failing Swift file.

Solution 1: Add the Swift Package product to the target

If the package appears in Xcode but import still fails, verify that its product is attached to the target.

For a Package.swift-based target:

// swift-tools-version: 6.0

import PackageDescription

let package = Package(
name: "MyPackage",
dependencies: [
.package(
url: "https://github.com/example/SomePackage.git",
from: "2.0.0"
)
],
targets: [
.target(
name: "MyTarget",
dependencies: [
.product(
name: "SomeLibrary",
package: "SomePackage"
)
]
)
]
)

Solution 2: Verify the correct module name

Inspect the package’s Product and Target definitions.

products: [ .library( name: "Networking", targets: ["NetworkingCore"] ) ]

Follow the package’s documentation for the correct import name rather than assuming the repository name is the module name.

Solution 3: Resolve Swift Package dependencies again

If dependency resolution is incomplete, ask Xcode to resolve package dependencies again.

For a command-line Swift package, you can also run:

swift package resolve

Run the command from the directory containing Package.swift.

Solution 4: Reset package caches

If package metadata or downloaded artifacts have become inconsistent, use Xcode’s Reset Package Caches option and resolve the dependencies again.

Solution 5: Open the CocoaPods .xcworkspace

A CocoaPods project commonly contains:

MyApp.xcodeproj MyApp.xcworkspace Podfile Podfile.lock Pods/

Open:

MyApp.xcworkspace

If you opened MyApp.xcodeproj directly, close Xcode and reopen the workspace.

Solution 6: Run pod install

From the directory containing the Podfile:

pod install

Then open the generated .xcworkspace.

Do not automatically use pod update when you only need to recreate the environment defined by Podfile.lock.

Solution 7: Check Link Binary With Libraries

Open:

Target → Build Phases → Link Binary With Libraries

Verify that the required framework or library is present for the affected target.

Solution 8: Check Framework Search Paths

For a manually integrated framework, inspect:

FRAMEWORK_SEARCH_PATHS

From Terminal:

xcodebuild -showBuildSettings | grep FRAMEWORK_SEARCH_PATHS

Make sure Xcode can actually search the directory containing the framework.

Solution 9: Check Library Search Paths

For static libraries:

xcodebuild -showBuildSettings | grep LIBRARY_SEARCH_PATHS

Verify that the required library directory is included.

Solution 10: Check Target Membership

If the missing module belongs to code shared between targets, inspect the relevant files in the File Inspector and confirm the correct Target Membership.

Solution 11: Check the deployment target

Compare the minimum OS version required by the dependency with the application’s deployment target.

Package: iOS 17.0+

App Target:
iOS 16.0

If necessary, raise the app’s deployment target or use an earlier compatible dependency version.

Solution 12: Check XCFramework platform support

For binary dependencies, verify that the XCFramework contains a compatible slice for the platform being built.

Apple’s current Xcode documentation shows that binary package dependencies can be inspected under Swift Package Dependencies and Referenced Binaries. :contentReference[oaicite:4]{index=4}

Example.xcframework/ ios-arm64/ ios-arm64_x86_64-simulator/

If no Simulator slice exists, the framework cannot be used for that Simulator build.

Solution 13: Check architecture support on Apple Silicon

Apple Silicon Macs normally run iOS Simulator code as arm64.

An older framework that contains only an x86_64 Simulator binary may therefore fail in modern Apple Silicon workflows.

Prefer an XCFramework that includes the required Simulator architecture.

Solution 14: Remove DerivedData

If the dependency graph is correct but Xcode still reports an old module error, clean the build folder:

Product → Clean Build Folder

If necessary:

rm -rf ~/Library/Developer/Xcode/DerivedData/*

Solution 15: Compare Debug and Release

If Debug works but Archive fails, compare search paths:

xcodebuild -showBuildSettings -configuration Debug | grep -E "FRAMEWORK_SEARCH_PATHS|LIBRARY_SEARCH_PATHS"

xcodebuild -showBuildSettings -configuration Release | grep -E "FRAMEWORK_SEARCH_PATHS|LIBRARY_SEARCH_PATHS"

Also check whether the two configurations use different .xcconfig files.

Solution 16: Check the selected scheme and target

With multiple application targets, you may simply be building a target that does not include the package or framework.

List available schemes with:

xcodebuild -list

Verify that the selected scheme builds the intended target.

Solution 17: Check test-target dependencies

If the error occurs in tests:

import SomeLibrary

// No such module 'SomeLibrary'

make sure the Unit Test or UI Test target can access that dependency.

A package product attached only to the app target may not be directly importable from a separate test target.

Solution 18: Check your own Package.swift target dependencies

For a custom Swift package, adding another package to the top-level dependencies list is not enough.

The dependency’s product must also be added to the target that imports it.

.target( name: "Feature", dependencies: [ .product( name: "UtilityKit", package: "UtilityPackage" ) ] )

Solution 19: Verify the package product definition

Check which products the dependency actually exports:

products: [ .library( name: "UtilityKit", targets: ["UtilityKit"] ) ]

Do not reference a product name that the package does not provide.

Solution 20: Check transitive binary-module dependencies

A custom framework or XCFramework may itself depend on another module.

That dependency may also need to be visible to the compiler at build time.

Swift community guidance for XCFramework dependencies notes that modules used by a binary framework must still be available through module definitions such as .swiftmodule, .swiftinterface, or module maps when required by the consuming build. :contentReference[oaicite:5]{index=5}

If a Swift Package was added but import still fails

Check these items in order:

1. Make sure the package resolved successfully.
2. Verify the product name.
3. Add the product to the target.
4. Check the dependency’s minimum platform requirement.
5. Reset package caches if necessary.
6. Clean DerivedData only after the dependency setup is correct.

If CocoaPods reports “No such module”

Check:

1. The Pod is declared for the correct target in the Podfile.
2. Run pod install.
3. Open the .xcworkspace.
4. Verify the selected scheme.
5. Check that the build configuration uses the generated Pods xcconfig.
6. Clean the build folder.

If you manually added a framework

Verify:

• The framework belongs to the correct target.
• It is present in Link Binary With Libraries.
• It is embedded when required.
• Framework Search Paths are correct.
• The target platform is supported.
• The required architecture is present.

If Archive alone reports “No such module”

If normal Debug builds succeed but Archive fails, inspect the Release configuration:

xcodebuild -showBuildSettings -configuration Release | grep -E "FRAMEWORK_SEARCH_PATHS|LIBRARY_SEARCH_PATHS|SWIFT_INCLUDE_PATHS"

Look for Release-only xcconfig, dependency, or search-path differences.

If the error happens only in CI

A local Mac may already have dependencies cached while a clean CI environment does not.

For Swift Package dependencies, resolve them explicitly before the build.

xcodebuild \ -resolvePackageDependencies \ -project MyApp.xcodeproj

For a workspace:

xcodebuild \ -resolvePackageDependencies \ -workspace MyApp.xcworkspace \ -scheme MyApp

If the project uses private packages, also verify Git, SSH-key, or token authentication in the CI environment.

If Xcode shows a red import error but the build succeeds

Sometimes SourceKit or Xcode indexing temporarily fails to recognize a valid module even though the compiler can build it.

If the actual build succeeds, try:

1. Build the project once.
2. Resolve package dependencies.
3. Clean the build folder.
4. Restart Xcode.
5. Remove DerivedData if the editor remains stale.

What you should avoid

Swift Package Manager and CocoaPods normally configure dependency paths for you.

Manually accumulating search paths can make Xcode load an unintended framework version and can create different behavior between Debug and Release.

Also avoid repeatedly deleting DerivedData without first confirming that the package or framework is actually attached to the target.

Fast troubleshooting checklist

1. Verify the importable module name.
2. Confirm that the package or framework belongs to the affected target.
3. For SwiftPM, add the package product to the target dependencies.
4. For CocoaPods, open the .xcworkspace.
5. Run pod install or resolve Swift Package dependencies.
6. Check the deployment target.
7. Check the XCFramework platform and architecture slices.
8. Compare Debug and Release configuration.
9. Check test and extension target dependencies.
10. Reset package caches or DerivedData only after verifying the configuration.

Summary

Swift’s “No such module” error in Xcode means that the compiler cannot access the requested module from the target currently being built.

For Swift Package Manager, the most important check is whether the dependency’s product has actually been added to the target that imports it. Adding the package itself is not always sufficient.

For CocoaPods, run pod install and open the generated .xcworkspace. For manually integrated frameworks, check target linking, framework search paths, platform support, and architecture support.

If the configuration is correct but the problem persists, investigate package resolution, deployment-target requirements, Debug versus Release differences, XCFramework slices, test targets, and finally Xcode’s package, module, and DerivedData caches.