Building for iOS Simulator, but the linked and embedded framework ‘XX.framework‘ was built for

Everything you need to know is right in the error message: /Users/Cray/Library/Developer/CoreSimulator/Devices/807ED0BE-DF53-4914-8847-9708719ECD22/data/Containers/Bundle/Application/C9958BD8-FB34-4937-9072-89A103A92D22/Sky Tracker.app/Frameworks/SMHI_Parser.framework/SMHI_Parser: no matching architecture in universal wrapper The framework SMHI_Parser.framework was not built to include Simulator code (i.e. i386 and x86_64), so it can't be loaded in the Simulator. You (or whomever built that framework for you) need to build that framework for the Simulator when you are building your app for the Simulator.

Compatible Designed for iPad apps build against the iOS SDK and cannot link visionOS libraries or frameworks. Your app needs to be built for visionOS in order to link this library.

I have the same problem. error: Building for iOS Simulator, but the linked library 'lib.a' was built for iOS. We have some lib only used in generic device and would not called in Simulator. It was work in Xcode 11.3, but not in Xcode 11.4.I can use the legacy build system to resolve this error. But I think it's not the good solution.

I have same issue. Someone has good solution? I added arm64 to Excluded Architecture to run app in the iOS simulator. Like this. https://stackoverflow.com/questions/63607158/xcode-12-building-for-ios-simulator-but-linking-in-an-object-file-built-for-io M1, macOS12.0.1, Xcode13.1

+1I get:... Building for Mac Catalyst, but the linked library 'libcrypto.a' was built for macOS + iOS + iOS Simulator. You may need to restrict the platforms for which this library should be linked in the target editor, or replace it with an XCFramework that supports both platforms.As mentioned in the error, I _did_ build for macOS and iOS.----Edit:Looks like a new target has been introduced for Mac CATALIST:CFLAG -target x86_64-apple-ios13.0-macabi.

You're building for the Simulator, but are attempting to link a library built for actual hardware.

Followed your advice and used the codesign utility, the WikitudeSDK framework executable is definitely not signed. However, the OpenSSL framework executable is also not signed Okay, these frameworks will need to carry a signature though if they contain an executable. Regarding: Is there anything else I could try? Perhaps adding a build phase to my project that signs the framework after its copied into place? I am not sure how Cocoapods set's up and loads your Frameworks into the Xcode project, but essentially you would need to get to a situation similar to the following: Create a new iOS blank Xcode project with the app template type. Create a new iOS Xcode project with the template type of Framework. Build the new Framework project and then take the built Framework and drag it into your new iOS blank project and set Embed & Sign. Build and sign the project from step 1. Ch

But, if you need to make archive process it's not going to work, at first you need to specify arch 64 only simulator SKK - ref: https://stackoverflow.com/questions/63607158/xcode-12-building-for-ios-simulator-but-linking-in-object-file-built-for-ios

Actually, his code doesn't seem to use GameplayKit in any way, and as far as I can tell the GameplayKit framework isn't linked in to it directly.It appears that the GameKit framework (an entirely different framework, available from iOS 4 or so) is somehow trying to link to GameplayKit itself, and that is causing the error.Maybe changing the GameKit framework to Optional linking instead of Required would avoid the unnecessary dependency side-effects?I don't have a paid developer account, so I can't actually try doing a build with the iOS Device target instead of the simulator, and I don't think there is any way for me to poke around further. (If you want to mess with it, you just need to uncheck all the missing image files from the target, it will build without them.)

We use 2 static library in our project. Once the libs were added via Build Phases > Link Binary with Libraries, they are shown in the General > Frameworks, Libraries and Embedded Content. Unlike other frameworks, there is NO Do Not Embed option for these 2 static libs. So my guess is they are embedded into the final binary without code signing? And the problem is only found on the iOS 14.5+ devices.

The weird behaviour happened to me as well. I had the following setup: A.xcframework linked to --> Internal-Framework-A (not Embedded); Internal-Framework-A linked into --> the AppTarget; A.xcframework linked and Embedded into the AppTarget so it's available to the Internal-Framework-A.; What worked for me was setting A.xcframework as Optional in Build Phases > Link Binary with Libraries in the Internal-Framework-A project. More information about what that means can be found at: https://stackoverflow.com/questions/33038137/xcode-and-optional-frameworks . Maybe this scenario doesn't make that much sense in your situation.

Probably the easiest method would be to have another duplicate target. e.g. WeatherSimulator, WeatherDevice. Keep the app targets in sync, except for the link frameworks. The Simulator build won't have the framework. The device build will include the framework. Another option, perhaps, in your current setup (one target) might be to have the framework weakly linked. Add a Run Script phase to remove the framework on the Simulator. Not sure this will work, but worthy of a try.