So, basically, we are back to having two different code branches - one for selecting input device on MacOS and another for iOS?I was really hoping I can write the same code for both systems...Do you have to check at run time what system the app is running on?Or at compile time using pecompile directives?

Come on Apple! Loading PNGs doesn't seem to work. Help your developers...

This is very helpful, thank you! Finally was able to make matrix multiplication faster on GPU. It's weird it can't automatically pad the columns/rows to the multiple of 8, and you have to do it manually...

This is so exceedingly complex for such a simple problem…

I concur

I am experiencing exactly the same issue under exactly the same conditions in MTKView on MacBook Pro M2 Max. We must be the only 2 people in the world trying to render figures with sharp edges smoothly moving across the screen! We must be doing something wrong, because on the same Mac, the screensaver with smoothly moving curved lines looks beautiful. I also watched the 2021 WWDC video on frame pacing, and it does help to use present(drawable, afterMinimumDuration: 1.0/FPS), however it again only works when not maximised (or maximised and some controls are hovering on top). It seems that the system is ignoring afterMinimumDuration when it full screen mode with nothing else visible. I'm thinking that the only way out might be by computing "by how much the shape should move" based on the time elapsed between two calls to draw(). However, I'm not sure this time will actually correspond to how long this frame will be displayed on the screen later. Please, please let me know if you find a solution.

This can also be related to how the triple-buffering mechanism of the MTKView works. I think the following might happen. At the beginning of rendering, it has two "next" frames into which is can draw, none of them "in flight" yet. So it calls draw() for the first one, and then immediately after 1/120 second for the second one. Then after 1/120 second more no frames are ready and then after 1/120 both of the frames might be ready, and then frame skip happens, and it calls draw() again on two consecutive steps. I did the following experiment. Added usleep(20000) at the beginning of a draw() call, and added the Metal monitoring information onto the screen. It shows that the time between frames is sometimes still 1/120, even though it should be impossible, because I put delay of 20 ms into each draw() call. How is that possible? My only explanation is that it might be using multithreaded calls to draw(). Anyway, I'm running out of ideas ;)

This is still happening on MacBook Pro M2 Max with ProMotion enabled (but not when refresh rate is fixed to 60 FPS). There is a bug in ProMotion somewhere (when it's in full screen mode only). Setting afterMinimumDuration doesn't help.

Did you find any solution to this?

My answer doesn't include code, but I believe it will be helpful as I spent 3 days before I figured it out. You need to use a semaphore to control access to the "in-flight" frames, and the maximum of the "in-flight" frames should be equal to 3 (because MTKView uses triple buffering). To find out how to do this correctly is easy. Start a new "Game" project in xcode, and select the framework "Metal" (not "SceneKit" or "SpriteKit"), and you can skip tests generation. Then you can find the relevant code in the "Renderer.swift" file (or whatever language you selected). I commented out all the "cube rotation" rendering in the default project, and just left the drawable presentation. The glitch disappeared at 60 FPS when the window is maximised (or not). Additionally I tried rendering the full video sample with graphics at 120 FPS (by setting preferredFrameRate on the view), and it works marvellously. You can enable metal information display in the options to see that there is no fluctuation if frame rate. Well, there is, but not glitchy anymore. I'm using MacBook Pro M2.

My answer doesn't include code, but I believe it will be helpful as I spent 3 days before I figured it out. You need to use a semaphore to control access to the "in-flight" frames, and the maximum of the "in-flight" frames should be equal to 3 (because MTKView uses triple buffering). To find out how to do this correctly is easy. Start a new "Game" project in xcode, and select the framework "Metal" (not "SceneKit" or "SpriteKit"), and you can skip tests generation. Then you can find the relevant code in the "Renderer.swift" file (or whatever language you selected). I commented out all the "cube rotation" rendering in the default project, and just left the drawable presentation. The glitch disappeared at 60 FPS when the window is maximised (or not). Additionally I tried rendering the full video sample with graphics at 120 FPS (by setting preferredFrameRate on the view), and it works marvellously. You can enable metal information display in the options to see that there is no fluctuation if frame rate. Well, there is, but not glitchy anymore. I'm using MacBook Pro M2.

My answer doesn't include code, but I believe it will be helpful as I spent 3 days before I figured it out. You need to use a semaphore to control access to the "in-flight" frames, and the maximum of the "in-flight" frames should be equal to 3 (because MTKView uses triple buffering). To find out how to do this correctly is easy. Start a new "Game" project in xcode, and select the framework "Metal" (not "SceneKit" or "SpriteKit"), and you can skip tests generation. Then you can find the relevant code in the "Renderer.swift" file (or whatever language you selected). I commented out all the "cube rotation" rendering in the default project, and just left the drawable presentation. The glitch disappeared at 60 FPS when the window is maximised (or not). Additionally I tried rendering the full video sample with graphics at 120 FPS (by setting preferredFrameRate on the view), and it works marvellously. You can enable metal information display in the options to see that there is no fluctuation if frame rate. Well, there is, but not glitchy anymore. I'm using MacBook Pro M2.

Finally, Sonoma came out and all the problems went away! I guess I'll have to release my app with minimum MacOS version requirement of 14.0. Can't let the people see what happens on <14...

I am faced with the same problem, however it cannot be solved with the solution suggested by Quinn... It's even more sad, because I am trying to use an Apple library, MLX, in my xcode project (MacOS app)... I am building the MLX library from source as described here: https://ml-explore.github.io/mlx/build/html/install.html After building the MLX library, the following artifacts are produced: libmlx.dylib mlx.metallib I then copy these into the xcode project for my MaxOS app, and configure the build phases as follows: libmlx.dylib - embed into Frameworks directory, and "code sign on copy" - this works fine mlx.metallib - according to the MLX requirements, this has to be located next to libmlx.dylib in the Frameworks directory, otherwise libmlx.dylib cannot find it - however, xcode doesn't let me deploy mlx.metallib into the Frameworks directory, because it doesn't sign it, and then signing the whole app fails (exactly like the original poster of this question) However, if I deploy mlx.metallib to the Resources directory, then the whole app can be signed, but libmlx.dylib cannot find mlx.metallib, because it's located in a different directory within the app bundle. Please help! Again, this is especially sad because MLX is an Apple library, but I cannot use it within my xcode MacOS project, because it comes in two parts, one of which cannot be deployed to the Frameworks directory.