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

>> I drag the archived and exported framework directly into the project to useHaving a project item for the framework isn't enough. You have to tell Xcode that the app target links against the framework, and (assuming you want the framework to be incorporated into the app bundle) you have to tell Xcode to embed the framework.You do these things by selecting the project item in the navigator, then selecting the app target, then in the General tab, add the framework to either the Embedded Binaries section or the Linked Frameworks and Libraries section.

I'm not sure that it's a limitation, it seems to be a flat-out Xcode bug.Xcode produces different results before the framework has been built for an iOS device, compared with after.Xcode also seems to produce difference results depending on whether you embed first, or link first; and even whether you drag, or use +.And finally Xcode embeds absolute paths rather than ones relative to the build directory.I found a way to consistently get this to work: http://netsplit.com/xcode-two-apps-with-a-shared-private-framework-in-a-workspace

First，we meet compile error：building for iOS Simulator, but linking in object file built for iOS, file 'xxxxx/Pods/xxxx.a' for architecture arm64. Then，found many tutorial told that can be solved by add excluding arm64. Then，we meet this：No architectures to compile for (ONLY_ACTIVE_ARCH=YES, active arch=arm64, VALID_ARCHS=arm64 arm64e i386 x86_64, EXCLUDED_ARCHS=( arm64 )). so，how to fix it ?

If you created a Cocoa app Xcode project you should not need to add it to the Linked Frameworks and Libraries section. That section is normally used for adding non-Apple frameworks and libraries. None of my Mac apps written in Swift has the Cocoa framework in the Linked Frameworks and Libraries section, and they build and run.Clicking the Add button opens a sheet that will let you add any framework or library in the macOS or iOS SDK to the list of linked libraries and frameworks.

QuinceyMorris, thank you for your reply!Yes, seems like framework B is actually Objective C static library wrapped in framework.Could you please guide me or provide a link to detailed information how to import static library properly inside my Swift framework? I'm still getting Missing required module 'B'. I did the following:Unwrapped framework B, changed binary name from B to B.aAdded all the headers of framework B and the library file B.a to my frameworkSetup Import Paths and Library Search PathsAdded module.modulemap file:module B [system] { header include/B.h export * }Then built my framework successfully and included into Swift demo application to Embedded Binaries.Everything works on my machine, but if I try to build the demo application (which contains my framework), I'm getting Missing required module 'B'.Looks like I need to expose something from library B, but not sure.I was following these manuals:http://iosc

Yes, it doesnt seem to work. The iOS simulator doesnt build, or link. I dont have iOS 13 on my device yet to test that. On a Mac build it didnt work though although it compile and link. Even with WIFI capabilities when i wrote this: connection.activate() connection.connectionStatusHandler = { newStatus in print(newStatus) } let deadlineTime = DispatchTime.now() + .seconds(4) DispatchQueue.main.asyncAfter(deadline: deadlineTime) { print(self.connection.lastConnectionStatus) }The status was null and the handler was not called. Worth logging his I suppose.

The problem is a little bit more complicated, because you have (at least) two configurations as well: Debug and Release. If your framework is debugged and rock-solid, then you can use the Release configuration in other applications during debugging, but if you want to debug into the framework that's not a great approach.You can solve this problem as well as your device/simulator problem if you include the framework project as a subproject of each other application that needs it. That way the correct configuration/architecture gets built for whatever you're doing at the moment.In regard to your original question, I can only tell you what other people are doing, even though it's something that's explicitly unsupported by Apple. Some 3rd party iOS developers (including Microsoft) build the Intel architectures and ARM architectures separately, then 'lipo' them into a single fat framework. It happens to work for now, though of course I'm not r

Well in my case, just now, I was using one of my own frameworks (built through Carthage). When I stopped having Carthage build it, and just dropped the framework project into my project's workspace, I got past this error.Note that I was still using other Carthage built frameworks, just my own was freaking out for some reason?Additionally, once I had my Framework Project in my Workspace, I adjusted it's framework search paths to point to an absolute filesystem location of the Projects Carthage's Build/iOS (recursive) folder.--- Later ---nevermind, I had to re-archive the app and now the error is back again, but for a different framework I don't control. =(---- Later Still ----Ok, I got it! For me anyway, I needed to remove the dSYM files that Carthage generated from the Apps Resource Bundle.

Removing Fabric and Crashlytics also worked for me. The main issue seems to be the static framework. Their frameworks contain static library binary instead of dylib, which seems to be no longer supported(?) in Xcode 8 since iOS 8 (embedded) dynamic frameworks are supported. Well, I'm guessing here though. They should provide us dynamic frameworks that can be embedded for iOS 8 or above. Then, this problem will go away.

Just like @blaap, I too wasted most of a full day on this. My app uses a framework I built. The framework uses 'default build settings' including the Skip install set to NO. I wanted to use the automatic signing but that always produced an archive with the Distribute Content that @joerick mentions. It had been a while since I setup an app in the store so I forgot that it should say Distribute App. Once I followed @joerick advice, I quickly found and changed Skip install to YES and BINGO, I have Distribute App and Validate App both enabled!! Apple would do well to have some tips and suggestions so others don't burn up a day on this crap since the framework used default settings. FWIW, I also unchecked Allow Archiving for Simulator because that seems to disable the Distribute App and Validate App options. Instead, I just created an archive for Any iOS

Thank you for that, those steps have been very helpful.Went through these steps to Clean Build Folder on each project separately and then the workspace, then rebuilding the app scheme in the workspace. Same errors but command-clicking showed that there was a namespace thing (I think it's a namespace thing anyway); I had an xcdatamodel in which I accidentally used the same Entity names as the classes that were showing errors. Since I don't actually care about CoreData yet (I did, but changed my mind), I deleted the model file and voilà, the errors disappeared.However, I have noticed that there are still issues with the workspace picking up the changed API—but, at least now, it's only the API that I've changed in the last few minutes, not the earlier changes.After I got the Core Data stuff removed, it was building fine. I realized that I needed to make a minor change to the API—needed to add a method to one of the classes in the Model—so I made the change, then built the Generic schem