In my example it is continuous repainting of the screen. I measure FPS and display it on the screen. The "game" moves 50 pics across the screen at stable 40 fps for as long as I want, but after suspend/resume, it is down to 20 fps. Also for as long as I want. Actual numbers depend on pic and phone model, but it is always about a half of what it was after first suspend/resume. Every phone, every simulator.It could be different during the first few seconds, but I do not really care about the first repaint. A long-term effect is what I worry about. I can check with a no transparency pic, but the most pics we show over backgrounds have transparency one way or another.If you are worried about the way I measure FPS, the effect is also noticeable by less smooth movement of pictures. And, again, when I had String.drawAt, instead of UIImage.drawAt, everything went smooth. Amount of drawn strings affected fps, but it was not different before and after suspend/resume.

And yes, the problem also accurs with opaque image, but the drop is not 50%. In my case FPS went from 39 to 25 after suspend/resume.

It is not critical, I just recreated a view to get back initial performance. But I thought to bring it to Apple attention. Is not it a right forum? Should I use Feedback Assistant instead or Feedback Assistant + Technical Support Incident? Sorry for questions, I spend more time programming for another OS.

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.