Introduction

The error Could not find module for target 'x86_64-apple-ios-simulator' usually means Xcode can see a framework or module, but the binary or module interface does not include a simulator-compatible slice for the architecture being built. In older Intel simulator builds that architecture is x86_64; on Apple Silicon, the equivalent problem often appears as a missing arm64 simulator slice.

So the real issue is not the literal text of the error. The real issue is that the dependency was packaged for the wrong platform or architecture combination.

What Usually Causes It

This error commonly appears when you import:

• a framework built only for physical iOS devices
• a static or dynamic library missing simulator support
• a package artifact that was not bundled as an XCFramework
• stale derived data after changing build settings or dependencies

A device binary and a simulator binary are not interchangeable. Even if both are arm64, Xcode still distinguishes iphoneos from iphonesimulator.

First Check the Binary You Are Linking

If the dependency is a framework or library on disk, inspect its architecture slices.

lipo -info MyFramework.framework/MyFramework

If you are working with an XCFramework, inspect its folder layout instead:

find MyFramework.xcframework -maxdepth 2 -type d

A healthy XCFramework should contain separate variants for device and simulator builds. A plain framework that only contains device slices will compile for a phone but fail for the simulator.

The Modern Fix: Ship an XCFramework

The robust fix is to package separate archives for device and simulator and combine them into an XCFramework.

1xcodebuild archive \
2  -scheme MyFramework \
3  -destination "generic/platform=iOS" \
4  -archivePath build/ios_devices \
5  SKIP_INSTALL=NO \
6  BUILD_LIBRARY_FOR_DISTRIBUTION=YES
7
8xcodebuild archive \
9  -scheme MyFramework \
10  -destination "generic/platform=iOS Simulator" \
11  -archivePath build/ios_simulator \
12  SKIP_INSTALL=NO \
13  BUILD_LIBRARY_FOR_DISTRIBUTION=YES
14
15xcodebuild -create-xcframework \
16  -framework build/ios_devices.xcarchive/Products/Library/Frameworks/MyFramework.framework \
17  -framework build/ios_simulator.xcarchive/Products/Library/Frameworks/MyFramework.framework \
18  -output build/MyFramework.xcframework

That packaging format is what Xcode expects for distributing binary frameworks across multiple Apple platforms and architectures.

If the Dependency Comes From CocoaPods or Carthage

When a third-party dependency triggers the error, the fix is usually to update or rebuild that dependency rather than editing your app target.

Good first steps are:

• clean derived data
• remove old build artifacts
• update pods or rebuild Carthage frameworks
• confirm the dependency vendor supports simulator slices for your Xcode version

For old prebuilt binaries, the honest answer is sometimes that the binary is obsolete and must be replaced with an XCFramework or rebuilt from source.

When Excluded Architectures Helps, and When It Does Not

You may see workarounds that exclude arm64 for the simulator or otherwise adjust build settings to dodge the error. Those can unblock local builds in specific environments, but they do not fix a binary that was packaged incorrectly.

Use exclusion settings only when you understand why the mismatch exists. Do not treat them as a general solution.

Clean Rebuild Steps

After changing the dependency packaging, do a clean rebuild so Xcode stops using stale artifacts.

rm -rf ~/Library/Developer/Xcode/DerivedData
xcodebuild -workspace MyApp.xcworkspace -scheme MyApp -sdk iphonesimulator build

This is especially useful after swapping a plain framework for an XCFramework.

Common Pitfalls

A common mistake is checking only whether the binary contains arm64 or x86_64 and ignoring the platform. A device arm64 slice does not satisfy an iOS Simulator build.

Another mistake is trying to merge unrelated platform binaries with ad hoc lipo commands. Modern Apple tooling expects device and simulator variants to be distributed as an XCFramework, not as one improvised universal framework.

Teams also lose time by editing the app target’s architecture settings when the real problem is a third-party binary that was built incorrectly.

Finally, remember the date context: on an Intel Mac, simulator builds often reference x86_64; on Apple Silicon, the same packaging problem usually surfaces as a missing simulator arm64 slice instead.

Summary

• The error means the imported module is missing a simulator-compatible binary or module interface.
• Device and simulator builds are different targets even when the CPU architecture name looks similar.
• The durable fix is to ship the dependency as an XCFramework with separate device and simulator variants.
• Clean derived data after changing packaging or dependency versions.
• Avoid treating architecture-exclusion settings as a universal fix for broken framework packaging.