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.

Xcode has never run on iOS or by extension Vision Pro. You lose the Xcode connect once in immersive mode. So if stuck at a breakpoint, then you don't know about it. And the display isn't high enough res to read the laptop, but the virtual display is sided up enough that it works.

Note that the device is working fine on the actual hardware. So it's like the simulator isn't firing off the notification.

I only have tried this controller, but it's not specific to the controller. The simulator needs to forward the notifications to the app, so that it knows the contoller is connnected/disconected. https://feedbackassistant.apple.com/feedback/15673127

https://feedbackassistant.apple.com/feedback/15675361

Already followed all that and it doesn’t work.