Xcode 6.1: file was built for x86_64 which is not the architecture being linked (i386)

Make sure you have i386 and x86_64 listed in your Architectures in Build settings for your lib. Also set Build Active Architecture Only explicitly to No.

While the accepted answer has solved the problem, here is a little more since the problems is about the architecture, literally the binary files

1. Architecture in iOS

armv64: iPhoneX, iPhone 5s-8, iPad Air - iPad Pro

armv7 : iPhone3Gs-5c, iPad WIFI(4th gen)

armv6 : iPhone - iPhone3G

the above if for real devices

i386 : 32-bit simulator

x86_64 : 64-bit simulator

the above list is downward compatible, which means iPhoneX can runs with armv6 as well, and just can not fully utilize the functions of armv64

more info about iOS architectures can be found here:https://developer.apple.com/library/content/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/DeviceCompatibilityMatrix/DeviceCompatibilityMatrix.html

2. What is Build Active Architecture Only?

If selected "Yes", it will only build your framework to the "selected device", either real devices(armv) or simulator(x86_64 or i386).For "No", it will build your framework to your list of "Valid Architectures"

By default, in debug mode, it is "Yes"; and in release more, it is "No", which can save compiling time in debug mode and ensure your release project framework runs on all architectures that you specified.

Thats why the accepted answer worked by forcing the framework to build for all architectures, however by reading more you will know what is behind and can definitely save time in compiling your framework. Of course, more control in yourself as well.

So, if you are working on a framework, and want to import to another project, if you compile the framework with Build Active Architecture Only "Yes" with simulator(i386 or x86_64), and then import to your project with Build Active Architecture Only "Yes" with a real device(armv), you will encountered this error.

Looking to the error description:

file was built for x86_64 which is not the architecture being linked (i386) will imply you build your framework in 64-bit simulator and your merged project build with 32-bit simulator.

while a more common would be:

framework file was built for x86_64 which is not the architecturebeing linked (arm64):which implies your framework is built in simulator while your merged project is build with real device.

3. Extracting the framework

A common practice would be right click the framework and select Show In Finder, while most developers keep the Finder open, and the newly compiled framework will replace the old one, without closing Finder and reopen again. Yes it is right, but if you switched the build target device in between, the frameworks will result in different folders. Sometimes you think you have compiled your framework but indeed it is in another folder. My suggestions would be always select Show in Finder to prevent the framework you import is not the latest one.

The two different folders: Debug-iphoneos and Debug-iphonesimulator

I ran into this problem and the current solution got rid of the original error (i.e. unable to link i386), but then linked Frameworks (such as Alamofire) could not be imported into my project. The following solution fixed this problem.

1. In your target Build Settings -> Architectures -> Valid Architectures, add the value i386.

2. Next, delete the contents of your project's derived data folder. The contents of this folder are generated during build time and can be safely removed and Xcode will create a new one. To delete this folder in Xcode 8, go to File->Project/Workspace Settings, click on the grey arrow to open the folder location in Finder, and delete the contents.

3. Clean and rebuild.

4. If the build still fails, check the issue navigator for something that says Update to recommended settings. Click it and try again.
   If you don't see that option, change Build Active Architecture Only to Yes in build settings. This slows down build times which can be frustrating when switching between different devices frequently, however it might be necessary.