LLDB crash

We haven't been able to find any causes yet. We've fixed all of the main thread violations we've run into, and I've tried running the app with NSZombies enabled and all of the other memory error aids, but to no avail. It would be nice to gain insight into what might cause this crash.

Thanks a lot for helping Ziqiao, i've made a small iOS App that shows the issue which is available here: https://github.com/fgirardey/SwiftDataInheritance The step to reproduce are: Create a collection named Work Create another collection name Tech that has Work as a parent Kill the app, relaunch and see the crash happening when List is accessing to children through .childrenOrNil.

Hi everyone! I'd like to create an application for system monitoring using the Endpoint Security framework. I already have a working prototype, and now I am trying to expand its capabilities to capture more event types. So, I need to pass you a broad warning here. It is VERY easy to put together a test/development app that works in the basic sense that it runs and doesn't create any obvious failure, but is in fact fundamentally flawed and will fail over and over again under real-world conditions. Even worse, most of these failures will not be simple crashes or hangs in your product but will instead be a variety of strange failures everywhere else. See the forum threads here, here, and here for a few examples. Started looking at filesystem-related events as one of the most important ones for my use case. These seem to be supported fairly well by the framework (ES_EVENT_TYPE_NOTIFY_OPEN/CLOSE/CREATE/WRITE, etc.). However, the READ FILE event seems to be absent… Am I missing something here, or does the

Nice to know that the original issue goes away in the latest Beta. Regarding the crash triggered by the access to Item.children, if you can provide a runnable code snippet to demo the issue, I'll take another look. You have mentioned a few classes with inheritance, and so I think it is probably worth mentioning that over-using inheritance may impact your app's performance negatively. Concretely, with today's default store (DefaultStore), all the types in an inheritance hierarchy are persisted with one single table in SQLite. If your inheritance hierarchy has many classes, the table (columns and data) can be quite big, which can slow down the performance of fetching and inserting data. That being said, when adopting SwiftData inheritance, you might examine if that is a right use case. This WWDC25 session(starting from around 4:25) covers this topic a bit. You can take a look, if haven't yet. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thanks for that. The crashing code, frame 0 of thread 28, is in _dispatch_source_set_runloop_timer_4CF. I’ve seen this before, and some digging around in my own records points to an issue with CFNetwork (r. 26038149). I originally thought we fixed this back in 2022, but my latest reading of that bug suggests that the fix was not a complete fix. Rather, it was a mitigation that was intended to significantly reduce the occurrences of this crash. As to what you can do about this, the issue here is a race condition with CFNetwork and there’s nothing you’re doing wrong that’s triggering it. In terms of a workaround, I do have one suggestion for you: Try disabling the classic loading mode by setting the usesClassicLoadingMode property to false. This race condition is in the classic loader, so switching to the modern loader should avoid the issue. However, it’s possible that it might trigger other issues, so make sure to test your product thoroughly before shipping it that way. Share and Enjoy — Qu

Hi Ziqiao, I've tried with iOS 26 Beta 7 and since Beta 8 (landed tonight) on device (because my Xcode is stuck on iOS Beta 6, don't know why) and the problem is solved. I can now query CollectionItem with predicate that contains inherited properties. Now I have only got problems with accesses to the children property in List. When i got the following hierarchy and the SwiftUI view List access to the Item.children property I got another kind of crash. Category: Work (parent: none) Category: Tech (parent: Work) Thread 1: Fatal error: Never access a full future backing data - PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(0x9872c0007ba42159 ))) with Optional(7639D151-5D48-46AC-AB2A-7F0F50919AC5) But I guess it's a different kind of problem now.

The use of the inheritance, as shown in the above code snippet, looks fine to me, and I don't really see a crash by running the code on my iOS 26 Beta 7 simulator and device. So did you try with Beta 7, the latest Beta as of today, yet? Best, —— Ziqiao Chen  Worldwide Developer Relations.

Hello, Thank you for raising these concerns with AFM and OS versions. Re: However, when running the same build on a MacBook Air M1 (macOS 15) through iPad app compatibility, the app crashes immediately upon launch. Running a TF build from beta Xcode 26 on macOS 15.x through iPad app compatibility seems unreliable. A crash report can help diagnose the problem on the MBA which may be an isolated case for a specific configuration. Similarly, an Xcode project that shows the problem is ideal. All that said, let's: File a bug report for crash on launch (with details above) File a bug report requesting code-level guidance on how to use #available(iOS 26, *) with AFM See Feedback Assistant. DTS Engineer

Right. But the presence of a third-party crash reporter undermines the trustworthiness of Apple crash reports. I talk about this in Implementing Your Own Crash Reporter, and there was a really good (well, bad)-: example of this phenomenon in this recent thread. I see, thanks for sharing that. I'll look into it in more detail later with the team. Sorry about that. This is a known bug. The workaround, as explained in Posting a Crash Report, is to change the extension to .txt and attach that. Got it, I am able to attach the .ips crash report below now, thanks for the workaround. crash-2025-08-21-214703.txt

[quote='841772022, edysudarto, /thread/786553?answerId=841772022#841772022, /profile/edysudarto'] but the crash reports I shared here and in the bug report are all coming from Xcode organizer crash reports. [/quote] Right. But the presence of a third-party crash reporter undermines the trustworthiness of Apple crash reports. I talk about this in Implementing Your Own Crash Reporter, and there was a really good (well, bad)-: example of this phenomenon in this recent thread. [quote='855264022, edysudarto, /thread/786553?answerId=855264022#855264022, /profile/edysudarto'] I cannot select [the .ips] as the file seems disabled from the upload menu [/quote] Sorry about that. This is a known bug. The workaround, as explained in Posting a Crash Report, is to change the extension to .txt and attach that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I've attached the .ips crash report in FB17775979 since I cannot upload it here. Hope it can help with the investigation and there is any insight that can be shared with me. Truly weird crash as it seems we are the only one who faced this issue as I didn't found any other related thread to this yet.

Apple replied to my feedback that this got fixed in iOS 26 beta 4. Anybody else still facing this crash on iOS 26 beta 4? @DTS Engineer if the bug is fixed entirely, can you please comment about this bug resolution and make your comment Apple Recommended?