Was thinking of this more and realizing it probably has something to do with the private implementation, but I do have a .cpp file that defines and includes it: `#define NS_PRIVATE_IMPLEMENTATION #define CA_PRIVATE_IMPLEMENTATION #define MTL_PRIVATE_IMPLEMENTATION #include <Foundation/Foundation.hpp> #include <Metal/Metal.hpp> #include <QuartzCore/QuartzCore.hpp>` That .cpp is located in a library, whereas the framework is on the final link (but that's kind of what I'd expect).

I think the breakpoint I was hitting was just that I forgot to actually return the value (damn you C++ for not just treating that as an error!).

I've been digging into this and it seems like we maybe have to work backwards and have a PSO before we can query the reflection. The documentation seems to just throw out things and let you guess how to use them unless you are doing things the most straight-forward way (i.e. you don't have a multi-platform title with a bunch of pre-existing code that expects things to be done in a slightly different way).

Also, is it even possible to do entirely offline shader reflection then? It doesn't really seem like it, unless we can somehow use the command line commands to examine the bindings in the .air/.metallib files.

I'm still digging into this. Conceptually the run loop doesn't seem to be failing on anything. The very first command buffer commit yields a purple screen (not sure yet where this is coming from). I also wanted to mention that I am currently ignoring the run loop callback and instead using our normal frame cadence to do the swap. The part I'm least familiar with is definitely the code to set up the view in the first place. It is mostly straight from our Vulkan version that is using MoltenVK.

I think I have figured out that this is simply displaying the name we chose and our code is using Null because the buffers in question were not named. You can nuke this post!