Also when I have Swift 5 set in Xcode 16, is that 5.xx (f.e. 5.9 has interop) or 5.0?

I have C++ Xcode projects and Swift projects. These only work right now with a c-style bridging header. Apple doesn’t have any sample apps that build clang modules sinice they were released many years ago. Watched the WWDC on explicit modules, but then read these don’t work with Swift interop. Have a modulemap file, -fmodules defined, but Swift still can’t see the C++ sources. one of the strengths of Apple development was ease of interop between ObjC++ and C++. Have had to wait until Swift 5/6 for something not under a C-wrapper. My code is on Swift 5 if that matters. But switching to Swift 6 is a concurrency warning flood.

Already followed all that and it doesn’t work.

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

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

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

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 clickthrough to errors/warnings in .cpp files are fine. The clickthrough breaks when the error/warning is found in a header file.

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.

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.

The display link still has to be set to 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.

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.

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.

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.