Swift 6

You’re using a third-party crash reporter and it’s undermining your ability to debug this issue. This is not uncommon. I discuss this in way too much detail in Implementing Your Own Crash Reporter. My advice is that you remove your third-party crash reporter and then wait for new Apple crash reports to arrive. To illustrate the sorts of problems I’m talking about here, let me pull apart that second crash report, starting with this: Exception Type: EXC_CRASH (SIGSEGV) Exception Codes: 0x0000000000000000, 0x0000000000000000 Triggered by Thread: 0 This shows that your process crashed due to a memory access exception. That it, it was running some code that accessed an invalid memory location. Let’s look at the backtrace of the crashing thread: Thread 0 name: Thread 0 Crashed: 0 libsystem_kernel.dylib … mach_msg2_trap + 8 (:-1) 1 libsystem_kernel.dylib … mach_msg2_internal + 76 (mach_msg.c:201) 2 libsystem_kernel.dylib … mach_msg_overwrite + 428 (mach_msg.c:0) 3 libsystem_kernel.dylib … mach_msg + 24 (mach_msg.c:3

We have confirmed that the issue has been addressed in both beta 6 and beta 7. Thank you.

@DTS Engineer unfortunately yes. I reproduced with Xcode 26 beta 6 (17A5305f) and an iPad running iOS 26 beta 7 (23A5326a). The following code will produce the runtime exception. slider.addTarget( self, action: #selector(sliderValueDidChange(_:for:)), for: .valueChanged ) // ... @objc func sliderValueDidChange(_ sender: UISlider, for event: UIEvent) { print(event) } whereas changing the event parameter type to UIControl.Event doesn't produce it: @objc func sliderValueDidChange(_ sender: UISlider, for event: UIControl.Event) { print(event) } Do note that changing the action method body to @objc func sliderValueDidChange(_ sender: UISlider, for event: UIEvent) { print(Event: (event)) } has always been working fine, but that is because the String interpolation treats the event value as nil I believe (by printing an empty String).

I can confirm the same issue on iOS 26 beta 6. We have been using simultaneousGesture() as a workaround for the well-known bug, which is the same one BAR115 mentioned earlier. However, this workaround appears to be broken as well. At the moment, it seems there is no reliable way to use buttons inside sheets. This is just ridiculous.

The provisioning profile we are using is for in-house development. We understand that normally the in-house provisioning profiles expire after a year. However, after we rebuild and redistribute our app, the new in-house provisioning profile's expiration date cannot be updated. We tried to rebuild and redistribute the app in Jul 2025 and Aug 2025. The in-house provisioning profile expiration date still keeps on 6 May 2026, which is less than a year. Is there any other way to clear the cache (?) or update the expiration date of the in-house provisioning profiles?

I think this got fixed on the Xcode beta released today (6, but device version is beta 7). I say I think because it worked on my side, both 18.2 and 18.5. Very much appreciate everyone's time who addressed this.

@Bigby Woody Could you please test the code snippet I’ve provided in Xcode beta 6 and iOS 26 beta 7? I’d like to know if you’re still able to reproduce the runtime exception.

Hi! Sorry for the necromancy but this issue still persists in xcode 16.4 and xcode 26 beta 6 For now my choice of a workaround is to play with that Show live issues checkbox Such a frustrating bug for someone who tries to learn swift 🫩