Introduction

This linker error means one of the libraries or object files in your build was compiled for a different CPU architecture than the target you are currently linking. The message often appears in older Apple-toolchain workflows when an i386 simulator build tries to link a library built for another architecture such as arm64 or x86_64.

What the Error Really Means

The linker combines already-compiled binaries. At that stage, source code no longer matters. What matters is whether every input binary contains a slice for the architecture being built.

If the target is i386 but a library was built only for arm64, the linker cannot use it. That is why the failure appears even if the code compiled successfully earlier.

Inspect the Binary’s Architectures

On Apple platforms, lipo is the quickest way to inspect a static library or framework binary.

lipo -info libSomething.a

or:

lipo -info MyFramework.framework/MyFramework

If the output does not include the architecture your build currently needs, you found the mismatch.

Common Cause: Mixing Device and Simulator Builds

A classic mistake is linking a device build of a library into a simulator target, or the reverse.

• device builds typically target ARM architectures
• simulator builds target Intel or simulator ARM architectures, depending on the machine and SDK

Those binaries are not interchangeable just because they come from the same codebase.

Rebuild the Dependency for the Right Target

If you have the source for the library, the cleanest fix is to rebuild it for the exact target you need.

For Xcode projects, that usually means opening the dependency project and building the same configuration and SDK your app uses.

If the dependency ships prebuilt, ask for a version that includes the required architecture slice.

Universal or Fat Libraries

Older Apple workflows often combined multiple slices into one “fat” binary using lipo.

lipo -create libsim.a libdevice.a -output libuniversal.a

That can solve the problem if you legitimately have compatible binaries for the needed architectures. It does not solve a missing build artifact by itself. You still need all required slices first.

Check Build Settings Too

Sometimes the dependency is correct, but your target is trying to build an architecture you do not actually need. Relevant Xcode settings include:

• 'Architectures'
• 'Excluded Architectures'
• SDK selection for simulator versus device
• search paths that may point at the wrong build output

If the search path points at an old archive folder, the linker may keep finding the wrong binary even after you rebuilt the library elsewhere.

Modern Apple-Silicon Note

On newer macOS and iOS toolchains, i386 is mostly a legacy simulator architecture. If you still see it, check whether an old project setting or legacy dependency is forcing an outdated simulator target. In many cases, the best fix is not “make everything support i386 again,” but “remove the legacy architecture expectation.”

Common Pitfalls

A common mistake is looking for a source-code bug when the problem is really a binary compatibility issue. Another is rebuilding the app target but not rebuilding the third-party library that still contains the wrong architecture slices. Developers also often inspect the framework bundle folder but not the actual binary inside it. Finally, stale build products and search paths can make Xcode keep linking the wrong archive even after you think you fixed the dependency.

Summary

• The error means a linked binary does not contain the architecture slice the target currently needs.
• Use lipo -info to inspect libraries and frameworks.
• Do not mix simulator and device binaries.
• Rebuild the dependency for the correct target or obtain a binary that contains the needed architecture.
• If i386 still appears in a modern project, also inspect whether an outdated build setting is the real problem.