I have the same problem. XCode complains about "Transport Error" Also the Console command xcrun devicectl device info ddiServices --device <device-id> --verbose Shows: ERROR: Transport error (com.apple.CoreDevice.ControlChannelConnectionError error 0 (0x00)) -------------------------------------------------------------------------------- ERROR: Control channel connection timed out while in state preparing (com.apple.dt.RemotePairingError error 4 (0x04)) Right now, it is not possible to debug on a real Apple Watch.

I have the same problem with deployment target WatchOS 10.0, and the watch on 10.6.1 The Devices and Simulators window shows the following error for the watch. Apparently, XCode is unable to connect to the watch. The operation couldn’t be completed. (com.apple.dt.deviceprep error -25.) Domain: com.apple.dt.deviceprep Code: -25 Recovery Suggestion: The operation timed out. Try again. User Info: { DVTErrorCreationDateKey = "2024-10-15 12:53:25 +0000"; "com.apple.dt.DVTCoreDevice.operationName" = connect; } System Information macOS Version 14.6.1 (Build 23G93) Xcode 16.0 (23051) (Build 16A242d) Timestamp: 2024-10-15T14:53:25+02:00

I get the same message in the console with XCode 16, but it does not crash the app on startup. So maybe the crash is not related to the message. The missing dSym does seem to make it impossible to symbolicate crash logs.

Note that the following is a work-around. I urge everybody to file a bug-report with Apple, to make sure there is pressure on Apple to fix this. Others have suggested the CMSensorRecorder work-around. It turns out that the "Fitness Tracking" setting in the Settings App needs to be enabled for that to work. When the authorizationStatus is .restricted, then the user first needs to switch on Settings > "Privacy & Security" > "Motion & Fitness" > "Fitness Tracking" When the authorizationStatus is .notDetermined, then start the CMSensorRecorder. A "Motion & Fitness" privacy settings will be added to your app's settings, and the user will be asked to authorise by iOS. When the user accepts, authorizationStatus changes to .authorized and you can start the CMAltimeter. When the authorizationStatus is .denied, the user needs to switch on the "Motion & Fitness" privacy setting of your app. The following code worked for me: let status = CMAltimeter.authorizationStatus() switch status { case .notDetermined: // trigger a authorization popup let recorder = CMSensorRecorder() DispatchQueue.global().async { recorder.recordAccelerometer(forDuration: 0.1) } case .restricted: popupText = "Please switch \"Fitness Tracking\" on, in the Apple Settings app, under \"Privacy & Security\" > \"Motion & Fitness\"" showingPopup = true case .denied: popupText = "Please switch \"Motion & Fitness\" on, in the app settings" showingPopup = true default: print("authorized") } Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { timer in let status = CMAltimeter.authorizationStatus() if status == .authorized { timer.invalidate() self.altimeter.startRelativeAltitudeUpdates(to: OperationQueue.main) { (data, _error) in // handle altimeter data } } }

I suggest that everybody who has the issue, files a bug report to Apple, in order to get some priority on this.

I am having a similar crash in my app. It looks like the rendering engine in QuartzCore is running out of memory. Did you ever find the cause of the crash?

I had the same issue. It turned out you need to manually set "WatchKit Companion App Bundle Identifier" in the BuildSettings to the bundle identifier of the other app. So the value of that parameter in the settings for the iPhone app needs to be the bundle identifier of the Watch app and vice versa. Then restart XCode and Simulator to make it work. I hade all kinds of strange errors until I fixed that.

I have the same issue, and reported it to Apple. The issue for me seems to be that the missing file is looked for in directory <some_long_path_name>/Debug-watchos, while it is located in directory <some_long_path_name>/Debug-watchsimulator As a work-around, in the Terminal, cd to the <some_long_path_name> directory, and create a symbolic link as follows: ln -s Debug-watchsimulator Debug-watchos This works until the next time you do a "Clean build folder".

A user of my app had a similar crash, but now in NSURLSession::dataTaskWithRequest, also on 17.0 (21A5291j). It has the same vm_map_enter failed Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: SIGNAL 6 Abort trap: 6 VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter

I have the same problem. It's a bug in the simulator. Please report it to Apple.

I am having the same problem, and have filed a bug report with Apple. Did you find a work-around?

I am seeing the same issue with a number of users of my app on iOS 15.4.1 (19E258). I suggest we all file a bug report to Apple.

Old question, but as warning to others reading this. You should definitely submit and get your in-app purchases approved by Apple before releasing an app that uses them. For our app, we just released a new auto-renewable subscription and the version of the app that uses it at the same time. The app version got approved, but the subscription not. As the result, we now have a live app that uses a subscription that does not exist.

Did you ever found out what the cause of the crash was? I have several similar crash reports from users , but have not been able to reproduce it myself. Do you think it is suspicious that the UI layout is initiated from a pthread_exit ? Could that be a lead for finding the answer?

There is no config that is guaranteed to work. One of the other users reported the following feedback from Apple on the issue:"We understand that you are having issues with your type definition for .gpx files. At this time, there is no commonly-accepted Uniform Type Identifier for .gpx files and different developers have defined their .gpx declaration differently. This means that if two apps are installed on the same device that claim to open these files with different definitions, they won't interact correctly: from the user's point of view, only one of those apps, chosen seemingly at random, will be able to open these files."That is, if there are two or more apps that have given different Uniform Type Identifiers for the same file extension, then only some of them will appear, choosen at random.