LLDB crash

Your new example doesn't cause a crash in Xcode 26 beta 3 or Xcode 16.4 on my M1 Max Mac Studio with macOS 15.5. I wonder if it's something else. Are you on macOS 26 beta?

@Developer Tools Engineer thanks. The FB you linked is the right one. @darkpaw Here's a simpler repro without bindings that still crashes. import SwiftUI struct MyItem: Identifiable { var id = UUID() var label: String } struct HelloView: View { let element: MyItem var body: some View { Text(element.label) } } struct ForEachSubView: View { @State var elements: [MyItem] = [ MyItem(label: hello), MyItem(label: world), ] var body: some View { List { ForEach(elements, id: .id) { element in HelloView(element: element) // crash // Works ok: // Text(element.label) } } } } #Preview(ForEachSubViewRepro) { ForEachSubView() } Seems SwiftUI is internally invoking an OutlineList and then crashing when trying to walk a tree, despite the fact that MyItem has no children and no children keypath is specified in the List constructor. Thread 0 Crashed: 0 libswiftCore.dylib 0x1a9b458f0 _assertionFailure(_:_:file:line:flags:) + 176 1 SwiftUI 0x1cab7e9c8 ViewListTree.visitItem(_:force:) + 5232 2

[quote='792781021, retrograde, /thread/792781, /profile/retrograde'] The following repro case results in a previews crash on Xcode 26 beta 3 (report attached). FB18762054 [/quote] Thanks for reporting this. I believe the feedback you meant to reference was FB18792113 which I've made sure has reached the right team for the initial triaging of your issue. If we need more information we will reach out to you via the feedback mechanism.

It also crashes in Xcode 16.4 because what you're doing isn't valid. In your second example, line 28 is wrong. HelloView does not have any Bindings in it; it just takes a label parameter, so line 29 passes in element.label. Correct. Line 28 is treating your elements State var as though it's a binding, by adding the $ in front. And you're also adding the $ to the element part towards the end of the line. elements is a State var and element is a var whose label property is being passed into a view that does not have a Binding. This is why Preview crashes. It will compile if line 13 is this instead: @Binding var label: String, but based on what you're doing with label inside HelloView, i.e. you're not changing it, there's no need for it to be a binding var.

Simpler repro without generics. import SwiftUI struct MyItem: Identifiable { var id = UUID() var label: String init(_ label: String) { self.label = label } } struct HelloView: View { let label: String var body: some View { Text(label) } } struct ForEachBindingRepro: View { @State var elements: [MyItem] = [ MyItem(hello), MyItem(world), ] var body: some View { List { ForEach($elements, id: .id) { $element in HelloView(label: element.label) // crash // Works ok: // Text(element.label) } } } } #Preview(ForEachBindingRepro) { ForEachBindingRepro() }

Thanks for the response. No, but iPadOS apps should not include com.apple.developer.driverkit.userclient-access. Note that your construction of that entitlement is also invalid (it's a list of bundle IDs and requires approval to use), We realized this was for MacOS only and since our app is for iOS, we plan to remove this. The actual bundleId was approved and we just use a censored bundle ID here Assuming the contents you've posted are accurate, then this mismatch is the problem: Those dictionaries must match in order for your DEXT to load. Yes, we also noticed the missing idVendor in our driver entitlement and updated it to match the provisioning profile. However, the issue still persists—our DriverKit is realized but does not start in the TestFlight build. Local Build (works): After enabling the driver and connecting the hardware, the system logs show the driver is both realized and started successfully. TestFlight Build (broken): On the same hardware and sequence, the system only logs the realization of th

Our engineering teams will need to investigate this issue. We'd greatly appreciate it if you could open a bug report, include crash logs and sample code or models that reproduce the issue, and post the FB number here once you do. http://feedbackassistant.apple.com Bug Reporting: How and Why? has tips on creating a successful bug report.

Thanks for the above answer. I think my options here are very little then. My business relies a lot on Crashlytics, we can track bugs very easily and the alert system is a must for us. Unfortunately, I can't just disable it :(. This is also happening randomly to any user, so I can't even disable it on a reduced audience. Something we could do is to disable Crashlytics for a few seconds when app moves back to the foreground (when the crash is occurring), but I don't know if that disables Crashlytics completely to prevent Apple crash reports to get disrupted. Maybe my next question would be: Is really Crashlytics the problem here or actually the fact that we have two tools bothering each other?

I have created a sample project and submitted a bug report FB18771900. Basically any UIToolbar in a storyboard compiled with iOS 26 SDK will crash in iOS 18.

Thank you for your prompt reply and professional advice! I fully understand the risks of directly manipulating the implementation details of private classes, which indeed pose potential issues for code maintenance. The reason I adopted method swizzling is to catch and handle NSRangeException (array out-of-bounds) crashes that commonly occur in iOS apps. Such problems frequently arise in complex business scenarios and severely impact the user experience. For example: Index out-of-bounds caused by changes in dynamically loaded JSON data formats Inconsistent data states when arrays are operated on by multiple threads Desynchronization between data sources and view updates during complex UI rendering By swapping methods like objectAtIndex:, we’ve implemented unified interception of boundary checks, recording context information and returning default values before an out-of-bounds error occurs. This has effectively reduced the crash rate. However, as you noted, this solution does carry compatibil

I have a usdz from my architect that reliably does this Applevision crash. “stage it“ app also seems to have problems. But yah. Quick view also crashes the OS. Dim and then Apple logo. this is July 2025.

Digging a bit further, we can find the initializers for the class: (lldb) po [[UICornerConfiguration alloc] _methodDescription] : in UICornerConfiguration: Class Methods: + (id) capsule; (0x1853cb920) + (id) uniformBottom:(id)arg1 topLeft:(id)arg2 topRight:(id)arg3; (0x1853cb608) + (id) capsuleWithMaximumRadius:(double)arg1; (0x1853cb9d8) + (id) uniform:(id)arg1; (0x1853cb1e4) + (id) uniformEdgesWithLeft:(id)arg1 right:(id)arg2; (0x1853cb3a4) + (id) uniformEdgesWithTop:(id)arg1 bottom:(id)arg2; (0x1853cb2dc) + (id) uniformLeft:(id)arg1 topRight:(id)arg2 bottomRight:(id)arg3; (0x1853cb704) + (id) uniformRight:(id)arg1 topLeft:(id)arg2 bottomLeft:(id)arg3; (0x1853cb800) + (id) uniformTop:(id)arg1 bottomLeft:(id)arg2 bottomRight:(id)arg3; (0x1853cb50c)

Inspecting the UIVisualEffectView, it looks like the cornerConfiguration property is in fact available, but it just hasn't been exposed as a public API yet. (lldb) po [self cornerConfiguration]