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.

Here's the crash report, as downloaded using Xcode's organizer. Will this work? I redacted the app and framework names. All of our symbols are symbolicated, except for "MyFramework", which is a C++ library of ours whose only job is to decode video, so I think it's irrelevant to this crash. 2025-07-28_00-11-07.8114_-0600-ddc7ad494d0b81224d315ee28d9b96d7aca9a9ca.crash I'll take another look at that tech note. I've gone over it before, but maybe I'll find something if I look again. Thank you!

After having spent some time in the debugger, I've learned the following: It appears that BaseBoard and FrontBoardServices are not iterating over our UI hierarchy like I had wondered. It seems to be dealing with things like UI configuration, accessibility, edge insets and safe areas, orientation, displays, etc. In other words, things that our app shouldn't be responsible for. This leads me to believe this may not be our app's bug. I don't think I have enough information for a good bug report, though. BaseBoard does work on the main thread and on background, worker threads. There's an XPC interprocess communication manager that receives messages on a background thread--I presume from the OS--about things that have changed. It may not have anything to do with a race condition. It seems plausible it could also be that BaseBoard/FrontBoardServices is getting its state corrupted. BSIntegerMapEnumerateWithBlock gets called a lot. It wasn't very useful printing out what's passed into it. I could file a bug report, but still have no idea how to reproduce it, since I've yet to see the crash. Should I report it anyways?