Thank you for that detailed reply. You're making me want to learn more about the low-level details of process execution. And ARM assembly while I'm at it. Add it to the list I guess. What was it in the crash report that signaled that the invalid address was actually an offset and not a literal address? It never would have occurred to me that I would need to disassemble objc_msgSend in order to interpret the report.[1] Given that the crash seems to be happening after the user enters PIP, and also the presence of code that appears to be updating auto layout constraints in response to the changing trait environment that a transition to PIP likely entails, I'd guess we have a constraint somewhere that is referencing a deallocated view. That is what I would call an informed wild guess, because I haven't been able to recreate the thing myself. [1] Which can probably be trusted. I would love to get rid of Crashlytics and just use the Apple features, but as I'm sure you understand, that is not my decision to make.

I found your question because I am investigating a similar crash. I haven't solved mine yet, but perhaps this tidbit of info can help you: according to this Apple doc on investigating memory access crashes, if objc_msgSend is at the top of the stack trace, the crash is due to a zombie object. Perhaps running the app with zombie objects enabled will help.

A couple days later, this is the solution I came up with: Use the collection view cells directly as accessibility elements, and not the UIAccessibilityElement subclass proxies. Make sure the collection view's accessibilityElements array contains only visible cells in the correct order. Make sure the accessiblityFrame of the cells gets clipped by the screen bounds. Override contentOffset on the collection view so that only my code can set it. Attempts by the system to set it while VoiceOver is running are ignored. This is working very well. But, the worry persists that I'm just plain doing it wrong. Overriding contentOffset seems like something that should not be necessary, and I can't shake the feeling that it wouldn't be necessary if I were setting everything up correctly. Which is to say that I'm still open to someone coming in and telling me how best to accomplish this. But for now, I'm moving on, and I hope this solution helps someone who is googling.

Turns out the pageScrolled announcement not getting read out was my fault. I had overlooked something as I made experimental code changes and I was actually passing nil instead of a string. The complaint about the scrolling while swiping still stands, though.

We never were able to find a way to reproduce this bug in-house. However, it seems that Apple has managed, either accidentally or on purpose, to fix this crash with iOS 15. We have not seen a single instance of this crash on the new OS, and on iOS 14 it was our top crasher. If you had something to do with that, @edford, thank you.

I managed to track down a full raw crashlog for this crash. I have attached it below. 2021-05-27_05-30-20.0978_-0700-6ab64f98986d9df13cb5c94915b53debaf5e2748.crash Address sanitizer found no issues in our testing. I was able to track down and fix a memory leak, but that did not address the crash.

I thought you might ask for the whole crash log. Unfortunately we are using Crashlytics for crash reports and I have not yet found a way to access the raw crash report text. I just have a stack trace and some OS/device data that I assume was parsed from source log data. The other threads in the stack trace are invariably all idle, with nothing of note going on. I can try running the app with the address sanitizer enabled, but without knowing what the user was doing at the time of crash, it's a bit of a stab in the dark. Thank you for the suggestion nonetheless, I will give it a shot.