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

After experimenting a bit I'm concluding that this just isn't really a use case supported by the weak-linking mechanism. It looks to me like any time you're embedding a framework in your bundle, the Xcode build sequence is going to try and link its symbols, and if it's a universal app this will mean for both architectures. There's no workaround here even if you're doing things like setting different search paths and bundle locations for x86 vs. arm64. I think to make this work we would need a 'stub library' implementation of the framework for arm64 to get us past the link errors, but I'm still not confident the right thing would happen at runtime (which is, x86 would link with the x86 framework, arm64 would behave as if the optional framework is missing). If anyone from Apple or with expertise can confirm this conclusion, that would be appreciated! And this question then becomes, more generally, what's the approach to ha

As far as I know you cannot use the same library for arm64 iPhone and iPhone Simulator and instead you have to link each one based on the platform you're building. The best way I've found to do this is using the Other Linker Flags and then add an option for Any iOS Simulator SDK and Any iOS SDK. Then you use -lname_of_library to specify if you want to use an iPhone version or an iPhone Simulator version. I use a .xcconfig file to accomplish this. Here's a working example of linking to fmod for either simulator or device: OTHER_LD_FLAGS_SIMULATOR = $(DEFAULT_OTHER_LD_FLAGS) -lfmodL_iphonesimulator OTHER_LD_FLAGS_DEVICE = $(DEFAULT_OTHER_LD_FLAGS) -lfmodL_iphoneos OTHER_LD_FLAGS = $(DEFAULT_OTHER_LD_FLAGS) OTHER_LD_FLAGS[sdk=iphoneos*] = $(OTHER_LD_FLAGS_DEVICE) OTHER_LD_FLAGS[sdk=iphonesimulator*] = $(OTHER_LD_FLAGS_SIMULATOR) Hope this helps. References: https://developer.apple.com/documentation/xcode/adding-a-build-conf

Just incase if people wants to use an all in one a build script that will create simulator and device frameworks based on the selected schema.Here it is:# This is a modified script and it will ask the target to build separate libraries for simulator and device etc # On project folder it will be found under Generated-Frameworks folder # As per the documentations for XCode 10 Apple does not allow building FAT librares # Go ahead and check https://forums.developer.apple.com/thread/66978 and https://forums.developer.apple.com/thread/109583 # Enjoy NicoX :) set -e # If we're already inside this script then die if [ -n $MULTIPLATFORM_BUILD_IN_PROGRESS ]; then exit 0 fi export MULTIPLATFORM_BUILD_IN_PROGRESS=1 ############################################ # Options ############################################ REVEAL_ARCHIVE_IN_FINDER=true OUTPUT_DIR_NAME=Generated-Frameworks FRAMEWORK_NAME=${PROJECT_NAME} OUTPUT_DIR=${PROJECT_DIR}/${OUTPUT_DIR_NA

Not only do you have to @import AVKit, and @import AVFoundation, you have to also import both frameworks into your project. Here is a link to how to import frameworks under Build Settings: https://developer.apple.com/library/ios/recipes/xcode_help-project_editor/Articles/AddingaLibrarytoaTarget.html

I have a similar setup in which I don't understand why the conflict would take a place. I will first show the setup, and then share why I think there should not be such a conflict Linkage scheme is basic nested dependency case, where the dependency is static xcframework MyApp -> FirebaseAnalytics.xcframework (Static) MyApp -> MyFramework (Dynamic) -> FirebaseAnalytics.xcframework (static) I use Workspace to build MyFramework as a dependency Workspace (named HRS) * MyApp project ** MyApp target (links MyFramework.framework from Workspace -> MyFramework project) * MyFramework project ** MyFramework target When in Workspace I build MyApp, it first gives me warnings, such as duplicate output file '/Users/oleksiinezhyborets/Library/Developer/Xcode/DerivedData/HRS-etdtlgdbraymsbdmilzwmgmwkjgs/Build/Products/Debug-iphonesimulator/FirebaseAnalytics.framework' on task: ProcessXCFramework /Users/oleksiinezhyborets/Projects/tv_mobile_ios 2/MyFramework/FirebaseFrameworks/An

Yes I face this frequently in XCode 10.3, Mac OS 10.14.6 trying to archive an iOS private framework.Once in a while I am able to work around the problem by deleting the build products folder, and then, importantly, restarting my Mac.That worked twice this morning; this afternoon I have restarted 15 times and still cannot archive the framework.PS: I don't care about archiving the framework; it is embedded in an app I am trying to upload; it's the build phase of the framework during the archive phase of the app that is failing.Has anyone found a solution for this !!!!

I can confirm, that if your app isn't built with the iOS 11 SDK then it will run in letterboxed compatability mode. You can see this yourself, by running the iPhone X simulator, taking an app built against the iOS 10 SDK (usually in ~/Library/Developer/Xcode/DerivedData) and then dragging it into the simulator to load it.

You can add the shared code into a framework target and remove it from any other targets in the app. For the app target, configure your Xcode project to link and embed the framework using the General tab of the app target. For the app extension target, go to the General tab and add the framework to the appropriate list in that tab, but make sure that it is not embedded. The default configuration of targets in Xcode includes search paths to find the framework within the app bundle, so when the app extension looks for the framework, it will find the copy that you're embedding via the app target. — Ed Ford,  DTS Engineer

The best thing to do here is to make your framework into its own Xcode project, so that you can then include a reference to that Xcode project in all of your future test projects through the steps outlined in the Embedding Frameworks Tech Note. Swift 3 does not have a stable application binary interface (ABI) yet, so having a prebuilt version of the framework to use is not supported, as such a configuration will have problems unless all of the Swift code for the entire app and all frameworks is built by the same compiler.

Unsupported Architectures. The executable for Frameworks/opencv2.framework contains unsupported architectures '[x86_64, i386]'. This suggests that you’re trying to submit an Intel binary to the App Store. You mentioned TestFlight, so I’m assuming that you’re working on an iOS-based platform. These are all Arm based, so submitting an Intel binary is problematic. My best guess is that you’re trying to submit a simulator build. The best way forward here is to package your third-party framework as an XCFramework. This format supports multiple platforms — and remember that the iOS Simulator and iOS are separate platforms — and Xcode will automatically choose the right platform for each scenario. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com