After messing with the signing settings for a bit, I was able to get the authorization to stick.

I'm also getting this running an Intel build on Monterey 12.3.1 on an M1 Max Macbook Pro and Apple Studio Display. An Apple Silicon build does not produce the error.

Unfortunately no. My only solution was to essentially use a sledgehammer and disable all game controller support pre-catalina. Even though the API is available none of the commonly used hardware seems to be correctly identified before Catalina, and some things aren't fully supported until Big Sur.

The reported size grows to the hundreds of megabytes to several gigabytes with no apparent upper limit, and it happens when running a release build outside of Xcode, so it's likely to be related to caching or GPU capture. I'll write up a Feedback Assistant ticket, but it may be hard to reproduce since I don't have physical access to the affected devices.

The ticket link is: https://feedbackassistant.apple.com/feedback/9753271 I've verified that our BC7 textures are properly aligned--each mipmap's with and height are proper multiples of blocks (indeed, DirectX and Vulkan also freak out if they aren't). Since each block is 16 bytes this would enforce 16-byte size alignment as well. The pixel data for each level begins on a 16-byte boundary as well. Since our BC7 textures are generated offline I'm not sure what's actually stored in the padded space--the crash is in a swizzle so it's remotely possible there's a stray bit pattern that's causing problems. Most of our textures upload just fine, but I've isolated one that causes the crash and I'm going to try writing a stripped-down application that loads that one texture. The file uses the KTX format so I can also try loading it with MetalKit's texture loader to see if there's a difference there.

Thanks for the clarification. The docs claim supportsBCTextureCompression is only available on MacOS, hence the confusion.