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

Okay, reached out to Apple via Feedback and got a response. They brought to my attention that the binaries aren't .dylibs and framework binaries need to be dylibs. So even though Google distributes their Admob SDK as frameworks (GoogleMobileAds.framework, GoogleUtilities.framework, ect), the binaries apparently can't be embedded in the app like a 'dynamic framework'. I guess in Google's Xcode project they changed the Mach-O type to Static? I didn't even realize that was supported. Wonder why they don't ship these as static libraries instead of .frameworks? Is there any advantage to using a .framework over a static library in this case?If I just link to the framework (and not embed) the app will run on my device. I was thinking I needed to embed them, because GoogleMobileAds.framework is obviously not included in iOS and didn't realize the 'framework' wasn't meant to be embedded in the app like frameworks

If you’re building an app you should be able to do this as follows: Add a bridging header to your app. Include the Objective-C header in your bridging header. Add the static library (.a) to your project. Add that to your Link Binary With Libraries build phase. Looking at your screen shot it seems that you’ve already tried steps 1 and 2. The errors suggest that your bridging header isn’t being compiled as Objective-C. Make sure that C++ and Objective-C Interoperability build setting is set to its default value of objc. Taking a step back, sharing code in this way is going to get very clunky very fast. For example, a single static library can’t support both the visionOS and visionOS simulator platforms. If you want to share pre-built libraries between teams, it’s best to use an XCFramework. See Creating a multiplatform binary framework bundle. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ +

Remember to make the framework optional in Build Phases -> Link Binary With Libraries to support older iOS versions

Lipo-ing files from different platforms (simulator and device) isn't supported, but I don't know whether this has anything to do with your problem. It's certainly possible that C is being treated as an iOS library, and that's why it won't link into B. You could try building C for the simulator only, without using lipo, and see if that changes anything.>> Is there anything to do with modulemap?Look at the build transcript to see if it got as far as trying to create a module map for B. (My guess is that it did not.) The later error message about the missing module map may just be a secondary error, because the build of B never finished.>> If i remove Library C from Framework B then A is working fine.That's actually good news, because it narrows the problem down.Is there any need to use a static library? At this point, it may be quicker and easier just to compile C's files directly into B.

hi i solved it by adding MonoInterpreter (set ☑️ checkbox) and Link only Frameworks in iOS-Build Settings

I had the same problem, here's what fixed it for me in Xcode 11.4:1. explicitly set `type` to `.dynamic` for all `products` in Package.swift:.library( name: XXX, type: .dynamic, // add this targets: [XXX] ),2. re-add SPM libraries in Project / Target / Frameworks and Libraries:- what used to be XXX - Do Not Embed- now becomes XXX - Embed & SignAfter these changes, build & run on device and simulator works, along with archive & export, although I had some errors when exporting until I restarted Xcode and started over, after which it succeeded.Btw, my setup is a workspace which contains:- Single Swift package (XXKit) with multiple targets (modules), defining multiple products (libraries)- Main project with multiple targets (iOS app, Widget, Extensions) linking libraries from the XXKit package- Pods project (for 3rd party stuff which still doesn't support SPM)UPDATE:- with the above solution, Xcode actually can't export IPA without errors- real solution is

You need to read the dyld man page, which explains how these relative references work.When you create a framework (from the Cocoa Framework template) it assumes that the framework will be embedded within your application, so it sets the Runpath Search Paths (LD_RUNPATH_SEARCH_PATHS) build setting to include directories that the framework would appear in a typical app. If you’re not using the framework embedded within your app, things get more complex. Do you plan to use the framework just in your tool? Or in other situations do you plan to use the framework embedded within an app?Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

To everyone, who is also struggling with this issue - I'm glad to inform you that building with the new Xcode 14.0 beta version seems to fix the issue, but introduces some new ones: The widgets doesn't disappear anymore! They do disappear during the installation(which is normal), but appears again after the install completes. Sometimes the today widgets displays Unable to Load after update. The widgets built with the WidgetKit (the iOS 14+ widgets) shows only white (or black, depending on the device theme) on the screen after the update. Tapping on them opens the app, but the deep linking doesn't work. It looks like the widgets are gone. You can't add new one. The worst is phone reboot doesn't fix this bug. The only fix I've found so far is downgrading to version built with Xcode 13. Overall I can't run WidgetKit widget on iOS 15 iPhone. On iOS 16 simulator it works fine. Tested on iOS 15.4.1. Build uploaded to TestFligh

Nested frameworks are not supported on iOS. Please see the Embedding Frameworks tech note for more information, as well as alternatives to nesting frameworks.

It may be good to know that when I linked all used by MyFramework frameworks to MyApp which uses MyFramework app build successfully. It seems that frameworks in MyFramework aren't linked correctly, but only for the macOS project, in the iOS project, all work properly.