The function NSString NSHomeDirectory() gives a path to the user's sandboxed disk area in user/Library/containers: eg. inline-code-(NSString *)pathToDatabase NSString *path; path = [NSHomeDirectory() stringByAppendingPathComponent: @"Library/Application Support"]; return path; }

setINeedsDispay: is a message sent to the NSButton object. That has nothing to do with the run loop. It should result in the view object redrawing itself during the next render pass. https://developer.apple.com/documentation/appkit/nsview/1483360-needsdisplay?language=objc

I don't think threading is the issue. All the interaction with the UI is on the main thread's run loop.

That is what I'm doing. When the user selects a color with the Color Well an action message is sent to the App. The App composes an NSImage with that color and sends a setImage message to the appropriate Buttons with the new Image.

I'm using older (10-15yr) Apple keyboards. I swapped out the keyboard with another with no change. My system is: iMac (24-inch, M1, 2021). Testing in XCode, the 10 number keys and the decimal point no longer generate Keyboard NSEvents. All the other keys( + - * = etc) on the numeric keypad side work normally. Curiously, the 5 key on the number pad generates a mouseUp event.

From your link I gather that OpenGL uses left hand coordinates but they end up as right hand coordinates by the projection matrix transform. All I know is that in porting a project from OpenGL, in which I designed my geometry with right hand coordinates, to Metal I found that everything came out arse backward. Would you know how to set up a Metal projection matrix so that it works the same as in OpenGL?

Actually, I've decided that dispatch_apply is inappropriate to what I am doing. Rather, I've taken the loop out of the hands of dispatch and populated the queue with repeated calls to dispatch_async. From watching the WWDC video I got the idea that dispatch_apply would be more efficient, but that turns out not to be the case here.