It is probably connected to Upcoming changes to the App Store receipt signing certificate

Ok, I took a receipt from Sandbox environment and extracted the certificates used to sign it. The last cert was Apple Root certificate, but the first 2 were the already expired intermediate certificates. Anything signed with those MUST fail after February 7. The part with "Not After : Feb 7 21:48:47 2023 GMT" Certificate:   Signature Algorithm: sha1WithRSAEncryption     Issuer: C=US, O=Apple Inc., OU=Apple Worldwide Developer Relations, CN=Apple Worldwide Developer Relations Certification Authority     Validity       Not Before: Nov 13 02:15:09 2015 GMT       Not After : Feb 7 21:48:47 2023 GMT     Subject: CN=Mac App Store and iTunes Store Receipt Signing, OU=Apple Worldwide Developer Relations, O=Apple Inc., C=US ____________________ Certificate:   Signature Algorithm: sha1WithRSAEncryption     Issuer: C=US, O=Apple Inc., OU=Apple Certification Authority, CN=Apple Root CA     Validity       Not Before: Feb 7 21:48:47 2013 GMT       Not After : Feb 7 21:48:47 2023 GMT     Subject: C=US, O=Apple Inc., OU=Apple Worldwide Developer Relations, CN=Apple Worldwide Developer Relations Certification Authority ____________________ Certificate:   Signature Algorithm: sha1WithRSAEncryption     Issuer: C=US, O=Apple Inc., OU=Apple Certification Authority, CN=Apple Root CA     Validity       Not Before: Apr 25 21:40:36 2006 GMT       Not After : Feb 9 21:40:36 2035 GMT     Subject: C=US, O=Apple Inc., OU=Apple Certification Authority, CN=Apple Root CA

Ok, I tried using Restore Purchase item and it looks like the problem gets resolved (at least in sandbox!) with the help of certificate which is valid until Nov 17 20:40:52 2023 GMT. Looks like we'll have fun right before Thanksgiving day this time. If someone is willing to check with production, I can provide 1 line of code and a couple terminal commands. Then those of us who had issues with production builds will have a way out... At least for the users who contacted us.

@iago849 I finally resolved it a couple months ago. I'll post a solution later today.

Ok, let me share my findings (no matter how scarce), may be they will help someone. I did not use AVAudioPlayer's delegate in my code, but I had a collection of sounds which were supposedly playing and once in a while I iterated over that collection and deleted sounds with false isPlaying field. It resulted in a crash mentioned above, though it was extremely rare. Your situation may look completely different (like having a single AVAudioPlayer which gets deleted together with encompassing class), but the effect is probably the same. What I changed to finally get rid of the bug: I made AVAudioPlayerDelegate, which deleted the sound that just finished playing. My theory is the following. The sound playing code runs on another thread and when it finishes, it sets isPlaying to false (or whatever results in it returning false) and tries to call the delegate's finishedPlaying on UI thread, which involves some minor delay. Now what happens if you delete the AVAudioPlayer between those 2 events is probably what results in attempt to access the deleted player's delegate?.finishedPlaying. It is just a speculative guesswork, but it seems to fit the observed results: the crash, why it is so difficult to reproduce and why my changes fixed it.