The Apple App Store is saying my react native mobile app crashes on launch. I don't experience the same in my dev environment, neither in VScode nor in Xcode. When I run the app in Xcode, it compiles and works as expected but I found a message in the console output that indicates a possible thread inversion. In the provided backtrace, it seems to be related to a WebSocket connection in my React Native app. My app starts at a login page. Once the user enters their credentials they click login and a call is made to the app server which is hosted on Heroku. I think I should review the code related to the mentioned thread (TID: 1269068) and identify where the -[UIApplication applicationState] is being called. ChatGPT is suggesting to make sure that this call, and any other UI-related calls, are wrapped within a dispatch to the main thread. My knowledge of reading the backtrace is limited and i'm unsure how to map the backtrace to my actual javascript code. I've added the backtrace below: Thread Performance Checker: Thread running at User-interactive quality-of-service class waiting on a lower QoS thread running at Default quality-of-service class. Investigate ways to avoid priority inversions PID: 78136, TID: 1269068 Backtrace ================================================================= 3 xp1 0x0000000100ae679c -[SRRunLoopThread runLoop] + 44 4 xp1 0x0000000100ae0cc4 +[NSRunLoop(SRWebSocket) SR_networkRunLoop] + 56 5 xp1 0x0000000100ae50cc -[SRProxyConnect _openConnection] + 72 6 xp1 0x0000000100ae4584 -[SRProxyConnect _configureProxy] + 916 7 xp1 0x0000000100ae3d78 -[SRProxyConnect openNetworkStreamWithCompletion:] + 92 8 xp1 0x0000000100ae8530 -[SRWebSocket open] + 624 9 xp1 0x0000000100754804 -[RCTReconnectingWebSocket start] + 148 10 xp1 0x0000000100742b08 -[RCTPackagerConnection init] + 416 11 xp1 0x0000000100742948 __49+[RCTPackagerConnection sharedPackagerConnection]_block_invoke + 36 12 libdispatch.dylib 0x000000010389993c _dispatch_client_callout + 16 13 libdispatch.dylib 0x000000010389b3dc _dispatch_once_callout + 84 14 xp1 0x00000001007428fc +[RCTPackagerConnection sharedPackagerConnection] + 88 15 xp1 0x00000001007d1afc -[RCTDevSettings initialize] + 164 16 xp1 0x000000010072df4c -[RCTModuleData _initializeModule] + 96 17 xp1 0x000000010072d89c -[RCTModuleData setUpInstanceAndBridge:] + 2168 18 xp1 0x000000010072f3b4 -[RCTModuleData instance] + 1168 19 xp1 0x00000001006d7074 -[RCTCxxBridge moduleForName:lazilyLoadIfNecessary:] + 712 20 xp1 0x00000001007382d4 -[RCTModuleRegistry moduleForName:lazilyLoadIfNecessary:] + 140 21 xp1 0x000000010073823c -[RCTModuleRegistry moduleForName:] + 48 22 xp1 0x00000001007e2ba8 -[RCTPerfMonitor devMenuItem] + 92 23 xp1 0x00000001007e2a74 -[RCTPerfMonitor initialize] + 88 24 xp1 0x000000010072df4c -[RCTModuleData _initializeModule] + 96 25 xp1 0x000000010072d89c -[RCTModuleData setUpInstanceAndBridge:] + 2168 26 xp1 0x000000010072f5ec __25-[RCTModuleData instance]_block_invoke + 44 27 xp1 0x0000000100793d20 RCTUnsafeExecuteOnMainQueueSync + 52 28 xp1 0x000000010072f254 -[RCTModuleData instance] + 816 29 xp1 0x00000001006db97c __49-[RCTCxxBridge _prepareModulesWithDispatchGroup:]_block_invoke + 156 30 libdispatch.dylib 0x00000001038980f0 _dispatch_call_block_and_release + 24 31 libdispatch.dylib 0x000000010389993c _dispatch_client_callout + 16 32 libdispatch.dylib 0x00000001038a96ac _dispatch_main_queue_drain + 1428 33 libdispatch.dylib 0x00000001038a9108 _dispatch_main_queue_callback_4CF + 40 34 CoreFoundation 0x00000001803ee1b4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12 35 CoreFoundation 0x00000001803e88cc __CFRunLoopRun + 1936 36 CoreFoundation 0x00000001803e7d28 CFRunLoopRunSpecific + 572 37 GraphicsServices 0x000000018e7cdbc0 GSEventRunModal + 160 38 UIKitCore 0x00000001852bafdc -[UIApplication _run] + 868 39 UIKitCore 0x00000001852bec54 UIApplicationMain + 124 40 xp1 0x00000001004172e0 main + 96

In our placation there are instances of crashes that are happening in production. That we cannot quite reproduce. Looking at the crash report doesn't reveal much as the crashed thread doesn't give too much information of where to look for the root cause of the problem. In our app we are also using third-party libraries but I didn't see that they might be the cause for the crash. Crash report If someone can point me in the right direction to look for or how to investigate it. It would much appreciated.

There's a bug in the tabBarController when you have more than 4 tabs bar items. If you have a tabBarController with 5 items and that 5th item has a ViewController "A" that pushes another ViewController "B", suspending the app, using the home key causes the pushed ViewController "B" to be removed. ViewController "A" screen size is reduced by what looks like a tabBar sized space at the bottom. This bug only happens when the app is suspended in portrait orientation. This was working as expected prior to iPadOS 16 and is still an issue with iPadOS 17. Anyone else experience this issue? How do I bring this to the attention of Apple so that can fix this?

I ran the app using 'npx expo start' in VScode with no problem. I opened the .xcworkspace in XCode and the app launches with no problem. I submitted my app to the app store. It was rejected due to crash on launch: "We were unable to review your app as it crashed on launch. We have attached detailed crash logs to help troubleshoot this issue. Review device details: Device type: iPad OS version: iOS 17.1" Apple provided crashlog.txt files and suggests the following: " To address the crash in your app, follow these steps: Fully symbolicate the crash report. See Adding Identifiable Symbol Names to a Crash Report for an explanation of the symbolication process. Match the crash report to a common pattern. Based on the pattern, take specific actions to further investigate the crash. See Identifying the Cause of Common Crashes. I previously ran a few terminal commands to symbolicate the crash report. I got an output file but I don't know how to read it or figure out what it is telling me to fix. Here are the crashlog.txt files sent to me by apple: crashlog-34BD7151-519A-4F8E-AD9B-8BB922FF3C96.txt crashlog-0087B434-8F11-4042-B595-11896159348B.txt crashlog-B9A5CCF8-3E1A-49B6-A0F0-699B2EB303B7.txt I understand this part indicates a language exception but that's as far as I understood: "exception" : {"codes":"0x0000000000000000, 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":"SIGABRT"}, "termination" : {"flags":0,"code":6,"namespace":"SIGNAL","indicator":"Abort trap: 6","byProc":"xp1","byPid":3803}, "asi" : {"libsystem_c.dylib":["abort() called"]}, "lastExceptionBacktrace" : [{"imageOffset":968816,"symbol":"__exceptionPreprocess","symbolLocation":164,"imageIndex":3},{"imageOffset":179200,"symbol":"objc_exception_throw","symbolLocation":60,"imageIndex":9},

After update XCode to 15, I encountered a crash with UnsafeMutableRawPointer. To recreate the problem I write this simple test code. class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() test() } private func test() { var abl = AudioBufferList() let capacity = 4096 let lp1 = UnsafeMutableAudioBufferListPointer(&abl) let outputBuffer1 = UnsafeMutablePointer<Int8>.allocate(capacity: capacity) let outputBuffer2 = UnsafeMutablePointer<Int8>.allocate(capacity: capacity) // It crashed here lp1[0].mData = UnsafeMutableRawPointer(outputBuffer1) lp1[0].mNumberChannels = 1 lp1[0].mDataByteSize = UInt32(capacity) lp1[1].mData = UnsafeMutableRawPointer(outputBuffer2) lp1[1].mNumberChannels = 1 lp1[1].mDataByteSize = UInt32(capacity) let lp2 = UnsafeMutableAudioBufferListPointer(&abl) let data = ( UnsafeMutablePointer<Int16>.allocate(capacity: 4096), packet: 1 ) lp2[0].mData = UnsafeMutableRawPointer(data.0) } } I checked the XCode 15 Release Notes and found out they did something with the pointer default initialization P1020R1 - Smart pointer creation with default initialization Is this causing the problem or I'm doing it wrong? Because it work perfectly fine with XCode 14.3.1 and below P/s: I can't provide the full crash logs cause it's company property but I can provide these: Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Triggered by Thread: 5 Application Specific Information: stack buffer overflow Thread 5 name: Dispatch queue: com.apple.NSXPCConnection.user.endpoint Thread 5 Crashed: 0 libsystem_kernel.dylib 0x20419ab78 __pthread_kill + 8 1 libsystem_pthread.dylib 0x23de0c3bc pthread_kill + 268 2 libsystem_c.dylib 0x1d780c44c __abort + 128 3 libsystem_c.dylib 0x1d77f7868 __stack_chk_fail + 96 Clearly there are something wrong with the memory address after init UnsafeMutableRawPointer from the UnsafeMutablePointer<Int8>

Hi, I've encountered this error on my app on crashlytics with the following stack trace, and I don't know what may be happening and how to prevent it. Crashed: com.apple.root.user-initiated-qos 0 libobjc.A.dylib 0x2470 objc_release + 16 1 libsystem_blocks.dylib 0x1834 _Block_release + 184 2 libdispatch.dylib 0x641a8 _dispatch_client_callout + 16 3 libdispatch.dylib 0x13568 _dispatch_root_queue_drain + 640 4 libdispatch.dylib 0x13c38 _dispatch_worker_thread2 + 172 5 libsystem_pthread.dylib 0x4e48 _pthread_wqthread + 224 6 libsystem_pthread.dylib 0x49f0 start_wqthread + 8

Has anyone else been unable to trigger item eviction? Note I am using MacOS Sonoma 14.1 on a Macbook Air M1. I have attempted using both the swift API myFileProviderManager.evictItem(myItemID) as well as the CLI tool fileproviderctl evict "path/to/myFile.txt" and both return Error Domain=NSFileProviderErrorDomain Code=-2008 "The file ‘myFile.txt’ cannot be evicted.". This error maps to the nonEvictable error. Therefore I attempted providing the necessary permissions to evict my file. I have attempted applying all 4 possible configurations of NSFileProviderContentPolicy to this file. I have tried the legacy option of using the capability .allowsEviction. I have even tried with NSExtensionFileProviderAllowsUserControlledEviction set to both YES and NO as I noticed Dropbox was able to evict items even though this option was set to NO. None of these attempts have succeeded. I noticed if I ran fileproviderctl evict "path/to/myFile.txt" --namespace I was able to see that the file has the contentPolicy of 1 which maps to the downloadLazily contentPolicy. The NSFileProviderContentPolicy code documentation states that with this configuration will "Allow eviction on low disk pressure and other triggers." For clarity here is a table of my various attempts with NSExtensionFileProviderAllowsUserControlledEviction set to YES: NSFileProviderContentPolicy With Evict Capability Without Evict Capability None (i.e. default) 2008 Failed to evict 2008 Failed to evict inherited 2008 Failed to evict 2008 Failed to evict downloadLazily 2008 Failed to evict 2008 Failed to evict downloadEagerlyAndKeepDownloaded 2008 Failed to evict 2008 Failed to evict downloadLazilyAndEvictOnRemoteUpdate 2008 Failed to evict 2008 Failed to evict What am I missing? Is the documentation outdated? Is this a bug? Any tips will be greatly appreciated!

I’ve just published an app which I only intended to put it into TestFlight as there are two issues i had hoped to resolve before launching in the App Store: It stops playing if phone is locked. If settings are changed they aren’t stored for the next time app is opened. I’m wondering if anyone here would be interested in collaborating on its development. One idea being to allow people to record their own sounds more relevant to their particular sport. This could be a paid option. I hope this kind of post is allowed. The name of the app is Distraction if you want to check it out to see if it would be of any interest to you.

Hello. I am currently developing a C++ application for x86_64 using XCode, and I am experiencing the same problem as described in the following link. https://discourse.llvm.org/t/lldb-doesnt-stop-on-sigabrt-assert-with-x86-executable-on-apple-arm/69749/1 Due to this bug, when the application crashes, it is difficult to tell which source code caused the crash, and this is reducing our development efficiency. How can this be fixed? Thank you in advance for your help.

Hi, I'm not a developer. I'm a start-up founder who recently launched a mobile app to the app store. The app passed the app store review and is live on the app store. I'm able to download the app on my device with no issues. However, when other iPhone users downloaded the app and opened it; the app crashed immediately upon opening. No black screen, just wouldn't open. I've asked my dev team about this and they mentioned that the mobile app is completely squared away from the developer/code side of things. Can anyone please help me understand why this app is not launching for other devices but launches perfectly on mine? My phone is an iPhone 12 Pro Max and I'm running on iOS Version 17.0.3. The mobile app is built on Flutter and NodeJS.

When I'm running my Mac app in the Xcode debugger, and it launches a helper app, the helper crashes with a dyld error. This does not happen if I am not debugging. Termination Reason: Namespace DYLD, Code 1 Library missing Library not loaded: @rpath/Cal3D.framework/Versions/A/Cal3D Referenced from: <3C1A67BA-5545-31A2-86C5-77104B0194FE> /Volumes/VOLUME/*/SBEngineLib4.framework/Versions/A/SBEngineLib4 The frameworks SBEngineLib4.framework and Cal3D.framework exist in the main app. The helper app does not contain any frameworks, but does contain dylib versions of those frameworks, which I suppose is confusing things somehow.

I implemented drag drop in my iOS app and sometimes, the dragged item gets stuck on the screen. The only way to remove it is by restarting the phone. Has anyone else faced this issue? And how did you resolve it?

I have a macOS app made with the Electron framework. Ever since I updated to macOS Sonoma, I've been facing a random crash whenever I click on the app menu/apple menu. This is not reproducible but happens quite often. On checking the crash report, I can notice that nil is being provided as an input to __NSPlaceholderDictionary initWithObjects method, but this crash does not happen in macOS Ventura or older versions. Is this due to any new validation added to the above method in macOS Sonoma ? Application Specific Backtrace 0: 0 CoreFoundation 0x000000018c6c08c0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000018c1b9eb4 objc_exception_throw + 60 2 CoreFoundation 0x000000018c5d7fa4 -[__NSPlaceholderDictionary initWithObjects:forKeys:count:] + 728 3 CoreFoundation 0x000000018c5d7ca0 +[NSDictionary dictionaryWithObjects:forKeys:count:] + 52 4 AppKit 0x000000019059d56c __NSSearchFieldCellGetSymbolImageDict_block_invoke + 3616 5 libdispatch.dylib 0x000000018c3c1910 _dispatch_client_callout + 20 6 libdispatch.dylib 0x000000018c3c314c _dispatch_once_callout + 32 7 AppKit 0x000000019059c368 NSSearchFieldCellGetSearchImage + 596 8 AppKit 0x000000018feea85c -[NSSearchFieldCell(NSSearchFieldCell_Local) _adjustSearchButtonCellImages::] + 216 9 AppKit 0x000000018fff2364 -[NSSearchFieldCell initWithCoder:] + 1040 10 AppKit 0x000000018fe6ed74 -[NSClassSwapper initWithCoder:] + 812 11 UIFoundation 0x0000000191161a64 UINibDecoderDecodeObjectForValue + 668 12 UIFoundation 0x00000001911617b0 -[UINibDecoder decodeObjectForKey:] + 312 13 AppKit 0x000000018fe6f2f8 -[NSControl initWithCoder:] + 368 14 AppKit 0x000000018fe6f744 -[NSTextField initWithCoder:] + 72 15 AppKit 0x000000018fff1ef8 -[NSSearchField initWithCoder:] + 52 16 AppKit 0x000000018fe6ed74 -[NSClassSwapper initWithCoder:] + 812 17 UIFoundation 0x0000000191161a64 UINibDecoderDecodeObjectForValue + 668 18 UIFoundation 0x0000000191161bec UINibDecoderDecodeObjectForValue + 1060 19 UIFoundation 0x00000001911617b0 -[UINibDecoder decodeObjectForKey:] + 312 20 AppKit 0x000000018fe30b6c -[NSView initWithCoder:] + 944 21 AppKit 0x000000018fe6e804 -[NSCustomView initWithCoder:] + 76 22 UIFoundation 0x0000000191161a64 UINibDecoderDecodeObjectForValue + 668 23 UIFoundation 0x00000001911617b0 -[UINibDecoder decodeObjectForKey:] + 312 24 AppKit 0x000000018fdfdecc -[NSNibConnector initWithCoder:] + 88 25 AppKit 0x000000018fdfde1c -[NSNibOutletConnector initWithCoder:] + 336 26 UIFoundation 0x0000000191161a64 UINibDecoderDecodeObjectForValue + 668 27 UIFoundation 0x0000000191161bec UINibDecoderDecodeObjectForValue + 1060 28 UIFoundation 0x00000001911617b0 -[UINibDecoder decodeObjectForKey:] + 312 29 AppKit 0x000000018fdfceb8 -[NSIBObjectData initWithCoder:] + 136 30 UIFoundation 0x0000000191161a64 UINibDecoderDecodeObjectForValue + 668 31 UIFoundation 0x00000001911617b0 -[UINibDecoder decodeObjectForKey:] + 312 32 AppKit 0x000000018fdfccd0 loadNib + 264 33 AppKit 0x000000018fdfc34c +[NSBundle(NSNibLoading) _loadNibFile:nameTable:options:withZone:ownerBundle:] + 560 34 AppKit 0x000000018fdfc050 -[NSBundle(NSNibLoading) loadNibNamed:owner:topLevelObjects:] + 180 35 Shortcut 0x00000001cc34f6d4 -[SCTSearchManager loadNib] + 60 36 Shortcut 0x00000001cc356bb8 -[SCTSearchManager akm_installShortcutView] + 200 37 Shortcut 0x00000001cc3569b4 -[SCTSearchManager menuNeedsUpdate:] + 24 38 CoreFoundation 0x000000018c640780 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 39 CoreFoundation 0x000000018c6d49a8 ___CFXRegistrationPost_block_invoke + 88 40 CoreFoundation 0x000000018c6d48f0 _CFXRegistrationPost + 440 41 CoreFoundation 0x000000018c60f434 _CFXNotificationPost + 764 42 Foundation 0x000000018d700c74 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 43 AppKit 0x0000000190445318 -[NSMenuTrackingSession sendBeginTrackingNotifications] + 204 44 AppKit 0x00000001904495f4 -[NSMenuTrackingSession beginTrackingSession] + 184 45 AppKit 0x00000001904ed170 -[NSMenuBarTrackingSession beginTrackingSession] + 188 46 AppKit 0x00000001904ec1e4 -[NSMenuBarTrackingSession _mouseDownEventHandler:] + 128 47 AppKit 0x00000001904ec14c -[NSMenuBarTrackingSession handleEvent:] + 248 48 AppKit 0x00000001904ec02c __61-[NSMenuBarTrackingSession _addMouseDownEventMonitorIfNeeded]_block_invoke + 192 49 AppKit 0x0000000190020624 _NSSendEventToDequeuingObservers + 252 50 AppKit 0x00000001905f919c -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2260 51 AppKit 0x000000018fe1843c -[NSApplication run] + 476 52 Electron Framework 0x00000001128cefd0 _ZN8electron5fuses45IsLoadBrowserProcessSpecificV8SnapshotEnabledEv + 94056 53 Electron Framework 0x00000001128cd4a0 _ZN8electron5fuses45IsLoadBrowserProcessSpecificV8SnapshotEnabledEv + 87096 54 Electron Framework 0x0000000115494168 _ZN2v88internal20SetupIsolateDelegate13SetupBuiltinsEPNS0_7IsolateEb + 18052380 55 Electron Framework 0x00000001154606ec _ZN2v88internal20SetupIsolateDelegate13SetupBuiltinsEPNS0_7IsolateEb + 17840800

Hello After updating my/our devices to iOS 17 (or XCode 15, not entirely sure), the custom fonts in our application have started randomly not working. Usually it will happen after the app has been in the background for a while. What happens is that: The fonts either don't load at all. For icon fonts, this means a lot of question marks. The fonts get swapped around, meaning regular text (Roboto, custom font) starts rendering using the icon font (Font Awesome). I can tell because I recognize the font from development. I have no idea how to reproduce it. I tried simulating the memory warning on the simulator, but that doesn't trigger it. It did not happen when building for iOS 16 and I did not change any font logic since then. It still does not happen on devices running iOS 17 but on versions of the app built with XCode 14. Some debug info: XCode: 15.0.1 (15A507) iOS: 17.1.1 (real device, I have not observed it on Simulator) We load the custom fonts from a proprietary SPM package: fileprivate static func registerFont(fontName: String, ext: String = "otf") { guard let fontURL = Bundle.module.url(forResource: fontName, withExtension: ext), let fontDataProvider = CGDataProvider(url: fontURL as CFURL), let font = CGFont(fontDataProvider) else { fatalError("Couldn't create font from filename: \(fontName).\(ext)") } var error: Unmanaged<CFError>? CTFontManagerRegisterGraphicsFont(font, &error) } public static func registerFonts() { registerFont(fontName: "Font Awesome 6 Brands-Regular-400") registerFont(fontName: "Font Awesome 6 Duotone-Solid-900") registerFont(fontName: "Font Awesome 6 Pro-Light-300") registerFont(fontName: "Font Awesome 6 Pro-Regular-400") registerFont(fontName: "Font Awesome 6 Pro-Solid-900") registerFont(fontName: "Font Awesome 6 Pro-Thin-100") registerFont(fontName: "Font Awesome 6 Sharp-Light-300") registerFont(fontName: "Font Awesome 6 Sharp-Regular-400") registerFont(fontName: "Font Awesome 6 Sharp-Solid-900") registerFont(fontName: "Roboto-Medium", ext: "ttf") registerFont(fontName: "Roboto-Regular", ext: "ttf") registerFont(fontName: "RobotoMono-Regular", ext: "ttf") } // Similar methods for all font types and icons: @objc public static func getDefaultFont(size: CGFloat) -> UIFont { return UIFont.init(name: "Roboto-Regular", size: size) ?? UIFont.systemFont(ofSize: size); } This code is the called in didFinishLaunching, and it would crash the app if it failed: FontHandler.registerFonts() To reiterate, all the fonts work when launching the app. Restarting the app always fixes it, which, combined with the fact that they get swapped around, leads me to believe that it's some kind of font caching issue. We use the fonts in code-only (no storyboards or xibs ever). A font would be loaded like this: let label = UILabel() label.font = FontHandler.getDefaultFont(size: 15) The font files ship with the SPM package itself, which contains the FontHandler class used above. import PackageDescription let package = Package( name: "MyPackageName", defaultLocalization: "en", platforms: [ .iOS(.v11) ], products: [ .library( name: "MyPackageName", targets: ["MyPackageName"]), ], targets: [ .target( name: "MyPackageName", resources: [ .process("Fonts") ]), .testTarget( name: "MyPackageNameTests", dependencies: ["MyPackageName"]), ] )

I've recently submitted a new app and got it refused as well because the app crashed on launch crashlog-13BCDAB6-3154-4F23-AB93-C6E118B84637.txt crashlog-E6C99809-6769-43AF-8B6D-CAB9A6125A3B.txt Context : The app is built using react native &amp; expo using the managed workflow. Some help would be greatly appreciated. Thanks !

I'm getting occasional crashes, which have not happened while running under a debugger and I haven't figured out how to reproduce. I wonder if anyone can help me glean more information from a crash report. Here's the main part. This particular report if from macOS 14.2 beta, but I've also seen it from 14.1.1. Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000018 Exception Codes: 0x0000000000000001, 0x0000000000000018 VM Region Info: 0x18 is not in any region. Bytes before following region: 140723250839528 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> mapped file 7ffcaf60c000-7ffcd7f48000 [649.2M] r-x/r-x SM=COW ...t_id=b7394f27 Error Formulating Crash Report: PC register does not match crashing frame (0x0 vs 0x1022A3630) Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 <translation info unavailable> 0x1022a3630 ??? 1 libsystem_platform.dylib 0x7ff819d0b393 _sigtramp + 51 2 AppKit 0x7ff81d3549a6 -[NSControl _setWindow:] + 59 3 AppKit 0x7ff81d413c19 -[NSSegmentedControl _setWindow:] + 42 4 AppKit 0x7ff81defd3be __21-[NSView _setWindow:]_block_invoke.391 + 324 5 AppKit 0x7ff81d33a62c -[NSView _setWindow:] + 1886 6 AppKit 0x7ff81defd3be __21-[NSView _setWindow:]_block_invoke.391 + 324 7 AppKit 0x7ff81d33a62c -[NSView _setWindow:] + 1886 8 AppKit 0x7ff81d572d08 -[NSWindow dealloc] + 922 9 MyApp 0x1011b6b81 -[JWWindow dealloc] (in MyApp) (JWWindow.m:37) 10 Foundation 0x7ff81b3d179c _NSKVOPerformWithDeallocatingObservable + 151 11 Foundation 0x7ff81acc6d54 NSKVODeallocate + 150 12 libobjc.A.dylib 0x7ff8199189d7 AutoreleasePoolPage::releaseUntil(objc_object**) + 169 13 libobjc.A.dylib 0x7ff819915cf0 objc_autoreleasePoolPop + 235 14 CoreFoundation 0x7ff819d794a1 _CFAutoreleasePoolPop + 22 15 Foundation 0x7ff81ac869ea -[NSAutoreleasePool drain] + 133 16 AppKit 0x7ff81d315694 -[NSApplication run] + 653 17 AppKit 0x7ff81d2e9662 NSApplicationMain + 816 18 MyApp 0x100ef5034 start (in MyApp) + 52 I can see that it involves deallocating a window as part of draining an autorelease pool, but does the presence of _NSKVOPerformWithDeallocatingObservable mean that KVO is involved somehow? And does the note "PC register does not match crashing frame" tell me anything?

HI I have many users experiencing the following crash at app launch: Date/Time: 2023-11-09 19:10:55.3851 +0800 Launch Time: 2023-11-09 19:10:54.1307 +0800 OS Version: iPhone OS 14.6 (18F72) Release Type: User Baseband Version: 3.04.01 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000818b75160 VM Region Info: 0x818b75160 is not in any region. Bytes after previous region: 23500116321 Bytes before following region: 32871329440 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL MALLOC_NANO 280000000-2a0000000 [512.0M] rw-/rwx SM=COW ---&amp;gt; GAP OF 0xd20000000 BYTES commpage (reserved) fc0000000-1000000000 [ 1.0G] ---/--- SM=NUL ...(unallocated) Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [20444] Triggered by Thread: 0 Thread 0 name: Thread 0 Crashed: 0 libobjc.A.dylib 0x000000019d5d2dd0 objc_release + 16 (objc-runtime-new.h:1589) 1 CoreFoundation 0x0000000188a2567c __RELEASE_OBJECTS_IN_THE_ARRAY__ + 116 (NSCollectionAux.h:70) 2 CoreFoundation 0x00000001889e774c -[__NSArrayM dealloc] + 276 (NSArrayM.m:473) 3 libobjc.A.dylib 0x000000019d5d457c AutoreleasePoolPage::releaseUntil(objc_object**) + 204 (NSObject.mm:944) 4 libobjc.A.dylib 0x000000019d5d441c objc_autoreleasePoolPop + 212 (NSObject.mm:1211) 5 FrontBoardServices 0x00000001980af6ac -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 248 (FBSWorkspace.m:356) 6 FrontBoardServices 0x00000001980cba0c __94-[FBSWorkspaceScenesClient createWithSceneID:groupID:parameters:transitionContext:completion:]_block_invoke + 372 (FBSWorkspaceScenesClient.m:364) 7 libdispatch.dylib 0x00000001886fb81c _dispatch_client_callout + 20 (object.m:559) 8 libdispatch.dylib 0x00000001886ff30c _dispatch_block_invoke_direct + 268 (queue.c:468) 9 FrontBoardServices 0x00000001980f3fa0 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 48 (FBSSerialQueue.m:184) 10 FrontBoardServices 0x00000001980f3c30 -[FBSSerialQueue _targetQueue_performNextIfPossible] + 448 (FBSSerialQueue.m:227) 11 FrontBoardServices 0x00000001980f4184 -[FBSSerialQueue _performNextFromRunLoopSource] + 32 (FBSSerialQueue.m:258) 12 CoreFoundation 0x0000000188a889e8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1967) 13 CoreFoundation 0x0000000188a888e4 __CFRunLoopDoSource0 + 208 (CFRunLoop.c:2011) 14 CoreFoundation 0x0000000188a87be8 __CFRunLoopDoSources0 + 268 (CFRunLoop.c:2048) 15 CoreFoundation 0x0000000188a81bc8 __CFRunLoopRun + 820 (CFRunLoop.c:2925) 16 CoreFoundation 0x0000000188a81360 CFRunLoopRunSpecific + 600 (CFRunLoop.c:3242) 17 GraphicsServices 0x00000001a00bf734 GSEventRunModal + 164 (GSEvent.c:2259) 18 UIKitCore 0x000000018b4fc584 -[UIApplication _run] + 1072 (UIApplication.m:3269) 19 UIKitCore 0x000000018b501df4 UIApplicationMain + 168 (UIApplication.m:4740) 20 xApp 0x0000000100ae0380 main + 128 (main.m:22) 21 libdyld.dylib 0x000000018873dcf8 start + 4 (:-1) I know that this can be a multithreading problem and it is related to NSMutableArray. But I cannot reproduce it and have no idea how to fix it. Any information will be welcome. Thanks

We have an iOS/iPadOS app that uses the ImageCaptureCore framework to communicate with PTP cameras. The same app also works with the 'macOS Catalyst' destination. But we like to deprecate the use of macOS Catalyst and then use 'Designed for iPad' destination instead. But when I use this destination then no cameras are provided to the app (ICDeviceBrowser)! :( I've noticed that on iOS devices the 'Settings app' usually shows that our app is allowed to use 'Camera'. But this possibility doesn't appear when the destination is 'Designed for iPad'. To my understanding below entitlements are used for a 'real' macOS app (including Catalyst), but I have added it anyway with: com.apple.security.device.camera com.apple.security.device.usb com.apple.security.personal-information.photos-library all set to YES and also the same privacy-related entries needed for iOS. Any pointers would be appreciated, thanks! :) macOS 14.1.1; Xcode 15.0.1

Hey everybody. I have a weird issue where I run my code with no issues. Then I run my code again, and Xcode crashes, without fail, every single time. Anyone have a similar issue? Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6 Terminating Process: Xcode [32564] Application Specific Information: abort() called Application Specific Signatures: NSInvalidArgumentException

Xcode contains several crash reports downloaded from users of my app. Thread 1 apparently crashes while performing a string interpolation. All the other threads only contain calls to system code. The String.appendingPathComponent(_:) that appears in the stacktrace is defined as follows: extension String { func appendingPathComponent(_ pathComponent: String) -&gt; String { return pathComponent == "" ? self : self == "" || self == "/" ? "\(self)\(pathComponent)" : "\(self)/\(pathComponent)" } } What could cause such a crash? Thread 1 Crashed: 0 CoreFoundation 0x00007ff81566f9df __CFStringEncodeByteStream + 120 (CFStringEncodings.c:692) 1 Foundation 0x00007ff8164c95aa -[NSString(NSStringOtherEncodings) getBytes:maxLength:usedLength:encoding:options:range:remainingRange:] + 204 (NSStringEncodings.m:341) 2 libswiftCore.dylib 0x00007ff822c6c1e0 String.UTF8View._foreignDistance(from:to:) + 208 (StringUTF8View.swift:507) 3 libswiftCore.dylib 0x00007ff822c56715 _StringGuts.append(_:) + 1445 (StringGutsRangeReplaceable.swift:191) 4 MyApp 0x00000001010c3c0f String.appendingPathComponent(_:) + 15 (&lt;compiler-generated&gt;:0)