I'd like to clarify that restarting the application does not fix the problem--only a full computer reboot does.

This is for a game under development. I can't reproduce the problem on either of my own Macs, but when opening a GPU trace made on one of the affected machines I clearly see that two textures (of ~50) are wrong (one is blue, the other corrupted). The two textures in question (as well as most others) are PNGs loaded via CGImage, copied to an intermediate MTLStorageModeManaged texture, then blitted to a MTLStorageModePrivate texture. Since I don't have physical access to the machine I haven't (yet) been able to narrow down where in this process the texture data becomes corrupted. Comparing a GPU trace of the same scene made on my machine I can tell the texture sizes and formats are correct--only the pixel data is wrong. I'll send off a Feedback Assistant post shortly.

I've now confirmed that the crash also happens using the texture loader from MetalKit. I've added a simple test application to the feedback ticket.

When signed with my development cert, codesign prints the following (with identifying information removed). When signed to run locally, it prints similarly appropriate information. In both cases an Intel-only build will run, but an Apple Silicon or Universal Binary build will not. Executable=/path/to/executable Identifier=executable Format=Mach-O universal (x86_64 arm64) CodeDirectory v=20400 size=1292 flags=0x0(none) hashes=30+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=d8cfc80142a15236c9fb1c7082746b0f0308685b CandidateCDHashFull sha256=d8cfc80142a15236c9fb1c7082746b0f0308685b33b47e362df97ebbb28b19f7 Hash choices=sha256 CMSDigest=d8cfc80142a15236c9fb1c7082746b0f0308685b33b47e362df97ebbb28b19f7 CMSDigestType=2 CDHash=d8cfc80142a15236c9fb1c7082746b0f0308685b Signature size=4779 Authority=Apple Development: My Name (XXXXXXXXXX) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Signed Time=Jan 11, 2022 at 2:15:25 PM Info.plist=not bound TeamIdentifier=XXXXXXXXXX Sealed Resources=none Internal requirements count=1 size=168 code-block I tried building a simple Hello World program from the command line, and it works fine when building for Apple Silicon. So the problem is likely something in the Xcode build settings, but nothing looks unusual to me.

No, it won't even run on the machine it's built on. And it's not crashing--there's no exception or crash log. Zsh seems to be killing the process before it can even hit main (I can't even get it to print out the usage text). When I have some free time I'm going to recreate the Xcode project from scratch--it's a few years old and has gone through various Xcode updates so maybe some wires got crossed somewhere. A few other projects I have seem to build and run properly, though they produce app bundles rather than a simple executable.

I tried it a few more times and did manage to get a couple crash reports in the console. It's a bit erratic--it doesn't log a crash every time it's killed. Anyway, from the crash log it's being killed due to the code signing, as expected: Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)).

The feeback assistant bug was closed since it's only affecting Mojave. https://feedbackassistant.apple.com/feedback/9462633

Some additional information: The Leaks instrument will work with An Intel-Only build, but not with an Apple Silicon build or a universal binary.

This crash is still occurring in MacOS Monterey (12.1, 12.2 and 12.3.1). We've confirmed it with end users with Intel HD Graphics 4000, Intel HD Graphics 5000, and Intel Iris Pro. One such device is a Macbook Pro 15" from 2015. I've updated the Feedback Assistant ticket as well.

Our mip levels are 16-byte aligned--each level is copied out of the KTX container before we use it. This crash seems to be specific to certain GPU and/or OS versions. We don't have this problem on any M1 system, or on most Intel systems. The feedback assistant ticket has a very simple MetalKit project that shows off the error.

The problem deleting parentheses seems to have been fixed as of 14.2, but the comment insertion is still happening. For reference, here's a link to the Feedback Assistant ticket I posted for the bugs: https://feedbackassistant.apple.com/feedback/9736474

I had the same problem with one the unit tests on one of my MacOS frameworks. I have no idea what caused it, but clearing the build folder and recreating the test target seems to have resolved it.

I also rely on external folder references and now I can't setup new projects. What is going on here?

This seems to be a side effect of Xcode 16 trying to force the use of project folders instead of groups--and it seems you can't have a folder reference inside a folder. If, however, you convert the enclosing project folder to a group, you can properly add a folder reference. You can then set the folder reference build rule to 'Apply Once to Folder'. The process is far more convoluted and twitchy than before, but at least it seems to work for now.

I'm running on an Apple Silicon laptop, predictive code completion is off, and I still get these warnings. It's very annoying.