Say the structure for project 'mylib' is: project/include/mylib.h project/include/header1.h project/include/header2.h project/src/file.c With the resulting framework structure something like: mylib/Versions/A/mylib mylib/Versions/A/Headers/mylib.h mylib/Versions/A/Headers/header1.h mylib/Versions/A/Headers/header2.h The new requirements wants only angle brackets in all framework headers, but that doesn't work for internal dependencies. Say 'header2.h' were to try including 'header1.h" with something like: #include <mylib/header.h> That include path will be incorrect when building the project--there is no real 'mylib' directory. Maybe Xcode hacks the include paths to magically work, but other toolchains have no way of doing that. Also, if there's an installed version of the headers in '/usr/local/include/mylib', a normal C toolchain will try to include 'header1.h' from there instead of from the project directory. It seems to me that Apple (or the clang devs) have redefined what angle bracket includes mean within the context of a framework, and the new definition is not compatible with non-Xcode toolchains. I currently have the warning disabled, but if at all possible I'd like to be creating properly structured frameworks.

Thanks for the response. To be clear, this is my own library so reworking how it builds (even abandoning frameworks) is no huge issue. Frameworks for iOS and MacOS are simply convenient packaging for the resources (and Metal shaders) that go with it. My main concerns here are to 1) make sure there isn't something wrong in my build settings, and 2) understand what's actually happening with the include paths. I actually tried a custom framework header, but the warning is triggered not only from the umbrella header, but from any of the headers included by umbrella header. It seems that all public includes are expected to only reference the system search paths. Regarding /usr/local, since that's kinda the typical place to install stuff on any Unix platform, so when installing as a static/shared library--even on Apple platforms--that's where it goes by default. The fact that an older version is installed somewhere on the system shouldn't break the build. Anyway, I've disabled the warning for the time being. If frameworks are no longer viable for cross-platform code it's seriously annoying and unfortunate, but not catastrophic.

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?