Hi! Does your binary make itself the active application before displaying the NSAlert? Adding a NSApplication.shared.activate(ignoringOtherApps: true) before showing the NSAlert might do the trick.

But why would a Dead argument cause a crash? The didSelectItemAt would look like this: class CollectionViewDataSource: NSObject, UICollectionViewDelegate, UICollectionViewDataSource { var sectionAHandler: (() -> Void)? var sectionBandler: ((URL) -> Void)? … public func collectionView(_ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath) { guard let section = Section(rawValue: indexPath.section), let item = self.item else { return } switch section { case .sectionA: sectionAHandler?() case .sectionB: if case .someEnum(let url) = item.urlKind { sectionBHandler?(url) } } } … } I try to resolve an enum defining the available sections, check if some item is available and if that is case, I switch on the section enum and call some function if available.

Yes, that was of course a typo. However, I cannot reproduce that error! The app and my code is running fine. The error is only visible in the crash reporting. But it's rare, really rare. I'm talking about 0.01 % of all app sessions. But I would like to understand and perhaps even avoid the crash.

Yes, I have the full crash log at hand. The crashed thread looks like this: Exception Type: SIGTRAP Exception Codes: TRAP_BRKPT at 0x102f59f38 Crashed Thread: 0 Thread 0 Crashed: 0 MyApp 0x0000000102f59f38 function signature specialization <Arg[0] = Dead> of MyApp.MyDataSource.collectionView(_: __C.UICollectionView, didSelectItemAt: Foundation.IndexPath) -> () (<compiler-generated>:0) 1 MyApp 0x0000000102f59258 @objc MyApp.MyDataSource.collectionView(_: __C.UICollectionView, didSelectItemAt: Foundation.IndexPath) -> () (<compiler-generated>:0) 2 UIKitCore 0x0000000183ab06e8 -[UICollectionView _selectItemAtIndexPath:animated:scrollPosition:notifyDelegate:deselectPrevious:performCustomSelectionAction:] + 896 3 UIKitCore 0x0000000183e4a300 -[UICollectionView touchesEnded:withEvent:] + 612 4 UIKitCore 0x00000001839940f8 forwardTouchMethod + 340 5 UIKitCore 0x00000001839940f8 forwardTouchMethod + 340 6 UIKitCore 0x00000001839940f8 forwardTouchMethod + 340 7 UIKitCore 0x0000000183903574 _UIGestureEnvironmentUpdate + 6704 8 UIKitCore 0x00000001839360b0 -[UIGestureEnvironment _updateForEvent:window:] + 780 9 UIKitCore 0x0000000183943250 -[UIWindow sendEvent:] + 4424 10 UIKitCore 0x0000000183af3918 -[UIApplication sendEvent:] + 824 11 UIKitCore 0x0000000183916464 __dispatchPreprocessedEventFromEventQueue + 7900 12 UIKitCore 0x000000018390b250 __processEventQueue + 6756 13 UIKitCore 0x00000001839106fc __eventFetcherSourceCallback + 168 14 CoreFoundation 0x00000001813b30d0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24 15 CoreFoundation 0x00000001813c3d90 __CFRunLoopDoSource0 + 204 16 CoreFoundation 0x00000001812fe098 __CFRunLoopDoSources0 + 264 17 CoreFoundation 0x00000001813038a4 __CFRunLoopRun + 816 18 CoreFoundation 0x0000000181317468 CFRunLoopRunSpecific + 596 19 GraphicsServices 0x000000019cea338c GSEventRunModal + 160 20 UIKitCore 0x0000000183cb9088 -[UIApplication _run] + 1096 21 UIKitCore 0x0000000183a37958 UIApplicationMain + 2088 22 MyApp 0x0000000102ea2870 main (MyAppDelegate.swift:15) 23 ??? 0x0000000103885aa4 0x0 + 0 Thread 1: 0 libsystem_kernel.dylib 0x00000001b88c5504 mach_msg_trap + 8 1 CoreFoundation 0x00000001812ff738 __CFRunLoopServiceMachPort + 368 2 CoreFoundation 0x0000000181303a2c __CFRunLoopRun + 1208 3 CoreFoundation 0x0000000181317468 CFRunLoopRunSpecific + 596 4 Foundation 0x0000000182b33c94 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 232 5 Foundation 0x0000000182b74dc8 -[NSRunLoop(NSRunLoop) runUntilDate:] + 88 6 UIKitCore 0x0000000183c32230 -[UIEventFetcher threadMain] + 520 7 Foundation 0x0000000182b8340c __NSThread__start__ + 804 8 libsystem_pthread.dylib 0x00000001f1d639a4 _pthread_start + 144 9 libsystem_pthread.dylib 0x00000001f1d62ea0 thread_start + 4 Thread 2: … Thread 3: … Thread 4: … Thread 5: … Thread 0 crashed with arm64 Thread State: x21: 0x40000002826da4c0 x2: 0x0000000000000001 x16: 0x0000000185a20ea8 x3: 0x0000000150928fa0 x22: 0x0000000103fa2aa8 x4: 0x0000000000000280 x17: 0x04f80001dbbb7688 cpsr: 0x0000000020000000 x5: 0x0000000150928fa0 x23: 0x00000001509285d0 x6: 0x0000000000000029 x18: 0x000000015500b940 x10: 0x00000000000d9f00 lr: 0x0000000102f59cc0 x7: 0x0000000000000001 x24: 0xc000000000000024 x11: 0x0000000000179f41 x8: 0x0000000000000003 x19: 0x00000002826c3780 x25: 0x000000016cf605d0 x9: 0x0000000000000005 x12: 0x00000000000030ef fp: 0x000000016cf605c0 x26: 0x000000016cf60080 x13: 0x00000000c7700670 pc: 0x0000000102f59f38 x27: 0x000000016cf60150 x14: 0x00000001041a4b60 x20: 0x000000016cf605d0 x0: 0x0000000000000005 sp: 0x000000016cf60080 x28: 0x0000000103fa2fc0 x15: 0x00000000c7700675 x1: 0x0000000000000005 And yes, it seems as if something gets deallocated faster than some other code would expect it to be gone. At least that's my assumption now.

I had to strip out the code from Thread 2 to 5 because of message size issues, they showed the usuals stacks anyway.

Ok, fixed an Xcode Beta bug (that fixed the Lock Screen in the simulator) and now I found the configuration view for Lock Screen widgets: you have to touch the widget once it is placed on the Lock Screen. The recommendations function isn‘t necessary for these widgets at all - and therefore it‘s never been called. Problem solved :P