So "delete" key does back, and "shift+delete" key does forward with no way to override or block this. Then my users lose all context, since the opening page is an empty splash screen that they're not supposed to be able to return to in the history.

Workaround for now is to make the app single-windowed with Window. Also openURL when using WindowGroup just makes a new Window when I really don't want it to.

The "Enter Fullscreen" menu item somehow disappears in some builds - could be Release builds. So not sure what is going on here.

-march=native is a pretty bad compile setting. You really aren't being specific then about the architecture. And for simd-based libraries you need to enable that too (-mavx2, -msee4.2, etc). I was using that arch that on Windows, and then the compiler uses whatever the SIMD architecture is of the machine that you compile upon. So I'd get AVX-512 code that would then crash on newer machines that omit that support. If you're running the Intel code emulated on Rosetta2, then you can expect a 2x slowdown there. Also note for Intel apps to run under Rosetta2, had to disable avx, and drop to SSE4.2. Also had to drop f16 support since neither of these are supported.

Even writing a file to the Containers tmp folder is marked as quarantine. This is using C style fopen()/fclose() calls. Then I open and copy the contents to another file in the same Containers folder (since tmp file will be removed). So both files end up with quarantine flag set. This all worked perfectly fine in macOS 11-13. So this is something that changed in macOS 14. I used to be able to sign app locally, and all would work.

kramv.perftrace Tmp file: com.apple.quarantine 20 Copied to ../Traces/ folder com.apple.LaunchServices.OpenWith 147 com.apple.lastuseddate#PS 16 com.apple.macl 72 com.apple.quarantine 20 clearing quarantine attribute, it returns after opening file in profile app com.apple.LaunchServices.OpenWith 147 com.apple.lastuseddate#PS 16 com.apple.macl 72 com.apple.quarantine 27 <- changed to 27

Okay, so this just seems to be the default behavior of turning on the App Sandbox. Even though sandboxed apps are able to write to the container folder, the files are marked as quarantine. That way the app can't open a script, or any other app can open the file without a permission query. For some reason, macOS never posts that permission query, and just posts that the file is damaged and should be moved to the trash. So I guess the lesson is to only enable hardened runtime and app sandbox in an App Store or otherwise distributable build, and not in the debug/release builds.

Would help if the docs mentioned this About sandboxes. This was a perftrace file, but it was just Perfetto json. So the files definitely get this attribute set. 20 seemed to be for a written file, and when attribute was cleared and then file is read changes to 27. Both are labeled as com.apple.quarantine. It’s also confusing since there is the Xcode setting for “app sandbox” which I hadn’t set, but sometime back I’d set the entitlement in prep for App Store. So some of the sandboxing was already applied. Now I just turned it all off. But will add back in a shipping build script. Seems like App Store builds are mostly about writing plist entries and not touching the Xcode settings. Otherwise, I can’t put these projects/apps up on github with team id and provisioning and signing and hardened runtime. This to too much work for free tools. We couldn’t actually put several Adobe tools in the App Store as a result.

So where should we set -mf16c in the compile settings? The vector instruction setting only takes SSE4.2, AVX, AVX2. This corresponds with an x86 named compile setting (really x64) and translates to say "-march avx2". For some bizarre reason, Xcode leaves f16c disabled if AVX or AVX2 are set. This is a major slowdown for macOS Intel apps. This despite AVX/AVX2 being tied into the f16c instructions. So then Apple Silicon nicely ignores the -march setting. But if you set -mf16c anywhere in the other compile flags, then the universal build complains that is an unused argument.

You use multiple command buffers, and request the drawable as late as humanly possible. You enqueue them, so they can be filled out in threads and sequenced properly. It's lame but nextDrawable is how the compositor throttles the app. Also make sure you have the MTKView set to framebuffer only. This will keep it linear for video scan out. Finally, don't run x64 through Rosetta 2, or Apple has some bug since macOS 11 that limits the top framerate to 60Hz. So you'll never hit 120Hz.

Also don't use 2 drawables. You need to triple buffer. 2 drawables is basically impossible to make work with the macOS and iOS compositor.

The display link still has to be set to 120hz.

IOSurfaces typically need to be returned to a pool (f.e. in video players and encoders). I don't see that you have any completion handler to release the surfaces back to any pool. Or you need to limit the ones you create, and recycle them. Or you can just upload buffers to a single MTLTexture, and then draw that to the drawable.

Depends on platform. GL allows reading/writing from the same texture. ES on iOS (and some Android) can also read from a buffer that's bound. Metal has the same functionality, but not AFAIK on macO Intel, only on iOS and Apple SIlicon. You can always ping-pong, but that may be costly. It's not that hard for the TBDR to read the pixels in the 32x32 tile, but there are a lot of ops being processed, and it can really only provide the color outside of the render pass. There are though ways to read the subpixels and pixels of a tile.

Note that clickthrough to errors/warnings in .cpp files are fine. The clickthrough breaks when the error/warning is found in a header file.