Xcode 11.4 : Building for iOS Simulator but the linked library was built for Mac OS + iOS

In Xode 11.4, I encounter a failure in my project.

When running my project, it was successfull in Xcode 11.3. Now in Xcode 11.4 I get the failure message:

Target Integrity: Building for ios simulator but the linked library ' my_library.a ' was built for may OS + ios.


The library " my_library.a is pointed to architecture: x86_64 and arm64 and never changed

I can run the Project on my device, but it is not running in the simulator.


Please help me what to do in Xcode 11.4. Do I have to change settings in Xcode 11.4.


regards, Robert

Accepted Reply

Having x86_64 code is not sufficient to distinguish if a binary is intended for the iOS Simulator, a macOS app, or a Mac Catalyst app. Combing built binaries across different destinations (which includes the simulator vs. device binaries) is not a supported combination -- there is no Apple platform where ARM code and x86_64 code in the same binary is a correct configuration.


If this is your library, you should have your app build it from source as a dependency of your Xcode project, either through an Xcode target or through Swift Package Manager, so that the right platform information is included based on the build target.


If this is your library but you have a specific reason for it to be pre-compiled, please build it as an XCFramework. XCFrameworks correctly separate out binaries that have the right architectures for the different platforms you target. In addition to instructions on how to build such a XCFramework linked earlier, we have a WWDC talk illustrating it.


If this library is from a framework vendor (either as source or a pre-compiled binary), or you integrate a vendor's library into your app with a third party dependency manager, please consult with the library vendor or dependency manager for support.

Replies

@robby28: Bosian's solution worked for me. My code also needed to only include references to the framework when not building for simulator, like so:


#if ! TARGET_IPHONE_SIMULATOR
#import <myDeviceOnlyFramework>
#endif


That should prevent linking failure errors.

I totally support you! Not even a note in the Release Notes of Xcode 11.4. I'm struggling with a similar problem for days now and the only thing that I have to support my need for recompilation of a third-party lib is a forum's answer. That's not good. This kind of disruption is not helpful for anyone.

@ccmargo - totally concur. Its beyond me why this is now a critical error.
I cant even strip a universal library down to its x86_64 arch in a script file phase, it errors prior to hitting the script. This is a huge disruption to developers who rely on 3rd party tooling.
Why does Apple constantly have to re-invent the wheel?

Post not yet marked as solved Up vote reply of vade Down vote reply of vade

We encountered the same problem. This is what I found out:


When a static library is added to the Xcode project (through Build Phases -> Link Binary With Libraries -> Add Other), Xcode automatically adds the relative path to that .a file to its file reference entry.


Prior to Xcode 11.4, this path was apparently removed during build, and replaced by the evaluated path generated from the current build settings, i.e. the actual configuration (Debug/Release) and the actual platform (iphoneos or iphonesimulator).


Starting from Xcode 11.4 however, this is apparently not happening anymore, and the build system is always using the explicit path set when the library was added.


By manually editing the project.pbxproj file for the iOS project, I removed the "path" attribute from the respective entries, e.g. changed from


  A15F487B16C934CE00D6F824 /* libmurl_engine.a */ = {
    isa = PBXFileReference;
    lastKnownFileType = archive.ar;
    name = libmurl_engine.a;
    path = "ios/Release-iphoneos/libmurl_engine.a";
    sourceTree = "";
  };


to


  A15F487B16C934CE00D6F824 /* libmurl_engine.a */ = {
    isa = PBXFileReference;
    lastKnownFileType = archive.ar;
    name = libmurl_engine.a;
    sourceTree = "";
  };


After this change, I was able to compile the project for both the actual iOS target as well as the simulator.


Hope that helps.

***? guys. i have precompiled sdk framework since 2017 year. It worked fine till xcode 11.4 updating. Why had apple broken backward compatibility for long time working precompiled Objective C frameworks? Why had they broken compatibility between precompiled swift frameworks also? What they will break next? Mac OS ?
Ah sorry guys. This was my mistake when using git lfs with cocoapods. Xcode 11.5 successfully completed compilation after properly resolving packages using git lfs.
But the problem with recompiling the swift sdk framework after each new xcode release still persists.
I was facing this error with OpenEdgeSDK when trying to build app in simulator, on Xcode 11.6. Wasnt facing the error in Xcode 11.3.
I tried exclusion of '***.a' but it didn't work. Changing shared workspace build system from New Build System to Legacy worked for me.
@edford How is this supposed to be handled when building a static library that contains assembly objects, assembled by yasm or nasm, which have no way to set the needed options indicating what exact target/version it's building for?