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

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.

Have you checked whether the library you are using is actually embedded in your SystemExtension ?At installation time it is going to be copied out of the App into a directory under /Library/SystemExtensions, so it needs to be entirely self-contained.For example, if it is linked against a non-OS framework, that framework needs to be in /Library/SystemExtensions/<UUID><your-system-extension>/Contents/Frameworks

The place to start is your list of undefined symbols. Pick one, say the class DLAVAlertView. What target/module/file/library/framework is the defined in? How does the project look like it intended to include this in the link? (For example, is it in the list of libraries and frameworks to link against, in the Info tab of the project editor for the target being built?) Or is it in a Build Phase that looks manually created? Is there a project item for it, and what does the Files inspector say about its path and/or referencing style?Once you've solved one, you'll presumably know what to fix for the others.

You cannot mix applications built against the iOS 15 SDK with iOS 14.* devices or simulators.

Hi, so it looks like User Agent sniffing will no longer work for iPad iOS 13+. If you have control over the devices, you could turn off the setting Request Desktop Website (Settings -> Safari -> Request Desktop Website (under Settings for Websites), but... I'm assuming you don't have control over the client device settings. Fix: I did find this fix Repeated link if the embedded one doesn't work: (https://stackoverflow.com/questions/9038625/detect-if-device-is-ios). Essentially, just tack on the solution to whatever current User Agent detection you are running. (copied below in case the answer is lost on Stack) function iOS() { return [ 'iPad Simulator', 'iPhone Simulator', 'iPod Simulator', 'iPad', 'iPhone', 'iPod' ].includes(navigator.platform) // iPad on iOS 13 detection || (navigator.userAgent.includes(Mac) && ontouchend in document) }

Binaries with GCC instrumentation have been rejected for some time, so doing the same for LLVM instrumentation doesn't surprise me - I don't know offhand if this is new or existing validation.As @FrankSchlegel noted in a different comment thread, the Xcode 9 release notes have this detail:Schemes with Code Coverage enabled (in the Test action) will now always build with Code Coverage, including for the Run and Launch actions. This reduces the need to build multiple versions of the application. Users who require code coverage to be off for their non-test actions can explicitly use a separate scheme with coverage disabled. (31848014) I ran a quick test and turned on this switch for testing. I saw that regular builds were indeed instrumented, but the archive builds were not. However, if any of your framework dependencies are copied into the final archived build product through a script instead of letting Xcode manage it for you with an Embedded Binar

Hello trvdatnielsen.I think you have to build different versions of your library in order to make it available for simulator and Devices.I started to build a framework to distribute to my clients as well.I have a question. What steps you follow to archive your framework? Will the Debug version be rejected by Apple validation?Regards,

I experienced the same issue with Xcode 7 GMld: in libSuperpoweredAudio.a(SuperpoweredAdvancedAudioPlayer.o), building for OSX, but linking in object file built for iOS, for architecture x86_64I have not found a workaround, yet

With Xcode 11 on macOS 10.15, the iOS 13 / tvOS 13 simulators support Metal. (The watchOS simulator uses Metal under the hood but Metal is not a public framework there).You can check out the new docs here: https://developer.apple.com/documentation/metal/developing_metal_apps_that_run_in_simulatorThis includes the ability to build projects for simulators that include metal files. When back-deploying to older simulators MTLCreateSystemDefaultDevice() will return nil.