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

I want to separate the components from the different contributors in this thread, as the underlying issue is not the same. @ethanrkaplan started this thread with an error message that points to a system framework, XCTest. And as he reports, there was an old build of their app involved, and removing at resolved this issue. The error message provided by @asiergmorato and also @anders.u point to libraries frameworks included by their apps, not Apple system frameworks, and so have a different set up and resolution to look at here. While I can't comment on @asiergmorato's circumstances more fully, as all we have is the error message here, @anders.u went ahead and opened a bug report (thank you!), so I have more information for their situation. @anders.u, you attached an XCFramework to your report that is a static framework, with the following bundle structure (edited for clarity): SomeKit.xcframework ├── Info.plist ├── ios-arm64 │ └── SomeKit.framework │ ├── So

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.

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.

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.

After a rebuild, the Modules folder was generated appropriatelly for device AND simulator, and the xcframework worked on both platforms... However, I still have one pod that we use for testing (Calabash), that is not an .xcframework (looks like it is a .dylib) and that trigger the ld: building for iOS Simulator, but linking in object file built for iOS error...

The correct way to distribute your framework is to build a version for the device, and a separate version for simulators, and have the clients of your framework conditionally link to the correct framework depending if the app's build is for simulator or for device. Using lipo to combine the device architectures with the simulator architectures is not supported.

Apperantly it works on ios 14 simulator. What i was doing wrong was i thought AppTrackingTransperency.framework was already added, which it wasn't. After i added that framework(in xCode -> Build Phases -> Link Binary With Libraries) it worked.

If the missing framework is one you build, the issue may be that building for Generic iOS device builds for all possible architectures. That means all the frameworks your app is linking with must be built for all architectures too. You may need to force build the framework for all architectures (Generic iOS device). If that fixes the issue, then there is some dependency issue in the project, whereby xcode does not realize to rebuild the framework before the app when switching configurations.

Some SDKs (…) write the below, Is this true?Well, it’s true that they write that (-: Seriously though, such a configuration is not supported by Apple. As I mentioned back on 11 Oct, all slices of a framework must be for the same platform, and iOS and the iOS Simulator are different platforms.I also want to stress that I completely agree that Apple should do a better job of supporting this. I’m not aware of any good solution to this problem. All of the available options have significant drawbacks. So, once all is said and done, and you’ve decided on an approach that works for you, I encourage you to file an enhancement request describing the problems you encountered and requesting a better solution.Furthermore as Bilm said (+1), would be great to have a suggestion on how to handle this without merging bothAgreed. Unfortunately I don’t have a good answer for you on that front. There’s three parts to this problem:CompilingLinkingEmbeddingYou can solve most of the compiling and

When it comes to building, embedding, and linking with dynamic libraries, I encourage folks to stay on the happy path that is rpath-relative library references. See Embedding nonstandard code structures in a bundle. Once you’re on that path you can embed your libraries in the Frameworks directory, per the advice in Placing Content in a Bundle. And once you do that, Xcode’s built-in code signing infrastructure tends to work well. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The script I presented does work with Xcode 9. Why not in Xcode 10?To be clear, this technique has never been supported. I’m not sure why it’s broken on Xcode 10, but that’s kinda the nature of unsupported things. For supported things Apple tries to maintain compatibility from release to release — and where we fail that’s worth a bug report — but we make no such promises for unsupported things.If you want to ship a pre-built framework that supports iOS and iOS Simulator, your only supported option right now is to ship two separate frameworks. The iOS framework should contain all the architectures you support on iOS (typically 64-bit Arm) and the iOS Simulator framework should contain all the architectures you support on the iOS Simulator (typically 64-bit Intel). Your clients will then have to link with the correct framework based on their build target.And ye

I can't seem to expose the public headers of the embedded framework from my framework to the main app.I can build the framework fine on its own. The only way I can get my app to run, is to link the embedded framework in my app also...but then I end up with two copies of the same framework and I have a mess on my hands.I tried adding a Copy Files build phase in my framework, and added the embedded framework there. But any public imports of the embedded framework fail when I try to build my main app.I know Cocoa.h imports frameworks:#import <Foundation/Foundation.h> #import <AppKit/AppKit.h> #import <CoreData/CoreData.h>It'll run if I keep the embedded framework imports private...but then my main app can't use any classes directly on the framework embedded in a framework.Edit: So I wiped the derived data. Th