This issue appears to be fixed with XCode 13. Metal libraries compiled in XCode are now working on iOS 10 for us, so you may want to remove your workaround.
I think the problem probably lies with the XCode packaging options rather than the Metal API.There's an option in `Build Settings`->`Compress PNG Files - Packaging` called `Compress PNG Files` which recompresses your PNG files with a custom version of PNGCrush, amongst other things (switching to BGRA IIRC), it premultiplies the alpha.
Post not yet marked as solved
Thanks for the response. To update on this:I tried the System Trace instrument and was able to view the wakeups that occurred, but I still couldn't work out what the ultimate cause of the wakeups was. If I had to guess now after digging into the AWS kinesis code I'd say GCD or NSURLSession seem the most likely sources.We did eventually get a more normal crash report (as opposed to the microstackshots report with the wakeups alert). The crash report led us to find a race condition in our analytics code (one thread wrote to an NSMutableArray while another thread read from it).After fixing the race condition we could no longer reproduce any crashes. This leads me to believe that the wakeups alert is a bit of a red herring. Reading around the kernel code that eskimo linked to, it looks like the wakeups count can either be fatal or be a warning. I now suspect that it was just a warning that didn't have anything to do with the crashes we were experiencing.I also found that our application had some code that was intended to prevent excessive uploading of analytics, but it had muddled milliseconds and seconds, so it wasn't effective. After verifying that crashes were no longer reproducible based on the race condition fix alone, we then fixed this bug. So, hopefully we've fixed the wakeups count too but we haven't really verified that.
