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

How to get iOS 16.7 simulator？

I have developed an app using Flutter that utilizes the Push to Talk framework on iOS. The Push to Talk feature works perfectly in debug mode, but after archiving the build and installing it on an iOS 17 device, the Push to Talk functionality stops working. Here are the steps I have already taken: Enabled background modes. Enabled Push to Talk capabilities. Despite these settings, the issue persists in the archive build. Has anyone else encountered this issue? What additional steps or configurations are required to get Push to Talk working in the archive build on iOS 17? Any help or guidance would be greatly appreciated. Thank you!

I am unable to use a framework that uses SwiftUI, built with the Xcode 16 release candidate, in Xcode 15.4. Attempting to build an app that uses the pre-built framework results in Cannot find type 'SwiftUICore' in scope errors in the framework's private swift interface (.private.swiftinterface) file. For example error: cannot find type 'SwiftUICore' in scope @_Concurrency.MainActor @preconcurrency public var body: some SwiftUICore.View { ^~~~~~~~~~~ The problem is reproducible by creating a new framework project in Xcode 16, adding SwiftUI code to it, adjusting the deployment target, building the framework, then creating a new app project in Xcode 15.4, adding the framework to it, and attempting to build. In my test framework, I added the following type: public struct BoldText: View { let string: String public init(_ string: String) { self.string = string } public var body: some View { Text(string).bold

Yesterday everything was fine. Could build blank templates to the device, no problem. Today, any attempt to build anything like a blank template to the device creates more than 21 errors. Looking like this:Cannot find interface declaration...Cannot declare variable inside @interfaceUknown type name UIGestureRecognizer...And a raft of other seemingly weird things that shouldn't happen. All in .h files that should be part and parcel of building to the device.As I say, building to a simulator has no such problems. Works fine, even with my terrible coding.

Hello, we have an issue that occurs only when updating devices OS from iOS 9 to iOS 10. Since we run out of all of our devices that were on iOS 9 and apple stopped signing iOS 9.3.5, we are no longer able to downgrade our testing devices back to iOS 9 for further testing purposes. We would like to ask following: Is there any way to test iOS system upgrade in the simulator?I was able to simulate it partially by copying files from iOS 9 simulator to a simulator with iOS 10, and then running the application, but was not able to complete this process yet due to some files missing on the iOS 10 simulator. I am still working on this solution.Is there still a way to downgrade back to iOS 9 for non-jailbroken devices?Thank you very much for your suggestions. Best,Matti

On iOS 10.x and earlier I could paste into the simulator by doing cmd-v, then cmd-shift-v. I confirmed this works in Xcode9, using the iOS 10.3.1 simulator. However, I can't get it to paste into an iOS11 simulator (regardless of device type). Did that functionality change somehow? I use it regularly...hoping it is just a command I don't know about!

On M1 mac (Apple Silicon chips), Xcode runs on arm64. How can we build the packages as x86_64 in SwiftPM that integrates with Xcode? Xcode builds the target as arm64 for simulator unless specifying excluded archs option. In some cases, the project would be forced to use x86_64 for simulator build since using external prebuilt frameworks only have arm64 for the device and x86_64 for the simulator. with specifying EXCLUDED_ARCHS[sdk=iphonesimulator*] = arm64 However, I could not find a way to specify that in the packages managed by SwiftPM. From this, Xcode builds packages as arm64 then builds application target as x86_64, linking phase would fail with not found modules in the arch. What can we do when we are forced to use still x86_64 on M1 mac?

how can I update my xcode simulator iOS to 11.0.3?

This is the crash log from device Last Exception Backtrace: 0 CoreFoundation 0x1da0cc288 __exceptionPreprocess + 220 1 libobjc.A.dylib 0x1f2dfb744 objc_exception_throw + 60 2 celsius 0x1030e4a18 RCTFormatError + 2378264 (RCTAssert.m:166) 3 celsius 0x102f002b4 +[CodePush ensureBinaryBundleExists] + 393908 (CodePush.m:370) 4 celsius 0x102eff79c +[CodePush bundleURLForResource:withExtension:subdirectory:bundle:] + 391068 (CodePush.m:159) 5 celsius 0x1030e6dd8 -[RCTBridge setUp] + 2387416 (RCTBridge.m:344) 6 celsius 0x1030e6620 -[RCTBridge initWithDelegate:bundleURL:moduleProvider:launchOptions:] + 2385440 (RCTBridge.m:212) 7 celsius 0x102ea5ff8 -[AppDelegate application:didFinishLaunchingWithOptions:] + 24568 (AppDelegate.m:38) 8 UIKitCore 0x1dc7d6a44 -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 340 9 UIKitCore 0x1dc9bda78 -[UIApplication _callInitializationDelegatesWithActions:forCanvas:payload:fromOriginatingProcess:] + 3572 10 UIKitCore 0x1dc9a6678 -[UIApplication _runWithM

Wondering is Metal debugging not supported with iOS simulator? When running a Metal app with Xcode on a real iOS device, by clicking on the camera icon on the debugger toolbar, the Metal debugger (a.k.a. Frame Capture Debugger) appears on screen for further investigation of issues with Metal shaders. That works with real iOS devices: https://developer.apple.com/documentation/metal/shader_authoring/developing_and_debugging_metal_shaders However when running the same Metal app with iOS simulator, the camera icon is grayed out, hence Metal debugger is unavailable for some reason. So is this simply not supported by the simulator or has there something else to be set up?

The only iOS 17 target available in Xcode 16.2's build settings appears to be iOS 17.6. But there are no simulators (at least that I can find) with anything beyond iOS 17.5. Therefore you can't test on iOS 17 with a simulator, because none will show as a deployment target. What is the expected course of action here? I'm sure there are many cases where developers need to test on iOS 17, but in mine I need to test the new framework for accessing a user's contacts; it has changed significantly, and I need to make sure it degrades gracefully on iOS 17. I'm not inclined to make my application inaccessible to 20% of the user base.