I'm giving up, this is a complete non-sense. I've tried: looking for as root and from root a specific file that was there in the folder: sh-3.2# find / -name "displacement.metal" 2> /dev/null. Nothing. Tried another recovery tool launched from an external drive to possibly not overwrite deleted content in my local disk. Nothing Had a look at if there was an APFS snapshot but I don't have any. This doesn't make sense at all. Even in the case that I've deleted that content manually, it would appear in the recovery tools. I have no clue how is it possible that something on disk can disappear without a trace. I've never seen anything by any means similar to this, never.

Well, I think I could found the culprit. First, doing it the other way around works: create a new Metal Library project and then adding a new target of Framework type. Looking at the differences of the "Build settings" between the metal library targets in both projects, this one: Versioning -> Versioning System was set to "Apple Generic" in the project that throws the error. Changing it to "None" works.

Ok, I answer myself: NSLog(@"Whatever: %@", error);

Hi! I saw what you mention in this sample code [https://developer.apple.com/documentation/metal/basic_tasks_and_concepts/using_metal_to_draw_a_view_s_contents?language=objc]. If I do the same in my test app then I get two calls: the explicit one and after it, the one that comes directly from NSApplicationMain->[MTKView _resizeDrawable]. After this second call the behavior is the expected and no more calls to drawableSizeWillChange are received. My implementation doesn't have the explicit call and I always receive the call from NSApplicationMain->[MTKView _resizeDrawable] on startup. I removed the explicit call in the sample code and it doesn't receive any call to drawableSizeWillChange when autoResizeDrawable = NO. What is more annoying is that it doesn't happen always.