LLDB crash

You haven’t provided the details about CollectionItem which seems to be the class that causes the crash but I must say that it’s a very strange design you have where the superclass both has a children property of self and is being inherited. Do you really need such a complex solution?

Hi, after few months, I haven't been able to solve this yet but apparently our Test Engineer able to reproduce this crash (accidentally) recently so I was able to ask them for the .ips crash report. I'd like to attach the file here, but I cannot select it as the file seems disabled from the upload menu. Any suggestion ?

I'm doing the following hack which works ok: I do not see any difference between this and using the .navigationLinkIndicatorVisibility modifier. It places a NavigationLink with no content over your view. ZStack { YourView() // Hack to prevent the disclosure indicator from showing NavigationLink(value: ScreenType.detail(toDo.guid)) { EmptyView() }.opacity(0) } // .navigationLinkIndicatorVisibility(.hidden) // Not properly backported to < iOS 26, so crashes on launch.

Update: I managed to reproduce the crash and solve it (I think). I had a scenario where the ModelActor in some cases would leak and stay transient after the user logged out. If another user logged in afterwards and another instance of the ModelActor would be created, this crash would occur. After I fixed the leak, the app seemingly no longer crashes. It's still a bit of a mystery to me, why it would crash though. The ModelActors are initialized with their own user-specific database, so they are completely distinct. My theory is that the leaked database could reference some resources that no longer existed after the user logged out and that caused the crash.

Removing the Entitlements.plist did solve the Validation failed (409) error, but my app was still crashing on launch in TestFlight. I had to add None to my csproj file to stop the launch crash, which means there is some kind of linker issue, but I haven't been able to narrow it down any further yet.

Hello, Quartz Debug is available as an additional tools package for Xcode. For example, Additional Tools for Xcode 26 beta 6 contains: This package includes audio, graphics, hardware I/O, and other auxiliary tools. These tools include AU Lab, OpenGL Driver Monitor, OpenGL Profiler, *****, Quartz Debug, CarPlay Simulator, HomeKit Accessory Simulator, IO Registry Explorer, Network Link Conditioner, PacketLogger, Printer Simulator, 64BitConversion, Clipboard Viewer, Crash Reporter Prefs, Dictionary Development Kit, Help Indexer, and Modem Scripts.

Hi, let us know on this thread if you hit this crash specifically on macOS 15.6.1+ and/or iOS 18.6.1+.

@usaagrumblemo, since you have a different scenario that you think is related, can you share some crash logs with us in a bug report? Please post the FB number here for reference. — Ed Ford,  DTS Engineer

What could be causing our app to fail detecting iBeacon regions when terminated, while third-party apps work correctly? I don't know specifically, but I suspect there is an issue with how your app handles being launched into the background. The typical pattern here is that the system did launch the app into the background, but then the app either crashed or never actually registered with CoreLocation, so it never received the message notifying it that it's beacon was discovered. The other possibility is that there is an issue with your beacon itself. Why does our iBeacon detection start working only after another iBeacon app triggers? I don't know, but my guess is that there's something more complicated going on and the 3rd party app is only an indirect factor. Are there specific implementation requirements or best practices for reliable background iBeacon monitoring? The main one is that your app needs to be able to fully launch in the background. Could this be related to iOS background app refresh

Observed a few times that providerDidBegin(_:) delegate never called for the complete app session after app init(as part of this CXProvider registered) which was built with SDK 26 and running on iOS 26. Yes, it looks like there is a bug there. More specifically, calling CXProvider.init(configuration:) kicks off an XPC connection to callservicesd on a secondary thread, the end of which eventually calls providerDidBegin(_:). If that completes before you're able to call setDelegate, then you'll see the problem you're describing. Oddly, as far as I can tell, the issue has basically been present from the beginning, so I'm not sure why I haven't heard of this before. Are you creating CXProvider on a background thread? I generally recommend using the main thread for CallKit and PushKit, and it's possible that initializing them on a background thread might make this problem more likely due to differences in thread priority. Moving to here: This issue was observed multiple times with our testing. Since there is no pro

@DTS Engineer thank you for these suggestions. I've added the full crash report from Crashlytics to this post. After enabling the launch argument you suggested, I managed to reproduce the crash in the debugger once, so that's some progress. After enabling Swift 6 and complete concurrency checking, I got some build errors in the class owning the ModelActor. Wherever I accessed the ModelActor, I got this error: Sending 'self.localStorage.some' risks causing data races. As mentioned in my original post, the ModelActor conforms to a protocol because I am using another type of storage in iOS 16 which doesn't support SwiftData. This protocol didn't require that conforming types were Actors, leading me to suspect that the class owning the ModelActor didn't treat it as an actor, because it only know about the protocol. Adding the Actor requirement to the protocol, removed the build errors in the owning class. Now, I have to ship this change to confirm that it actually fixes it, since I cannot reliab