So I'm trying to maintain free open-source macOS tools. These two tools are sandboxed and hardened runtime. One is an image viewer that writes out a perftrace file into the sandbox folder (in Containers). Then another app tries to open that perftrace file (json). When the perftrace file is opened in Xcode (signed and notarized), the file opens fine the first and all subsequent times. When the opening app is kram-profile (signed not notaraized), the file opens once and then nothing can ever open it again. The app has attribute com.apple.quarantine set on it. The only workaround to then open this file is to remove the attribute xattr -d com.apple.quarantine <filename> This is my tool build in Xcode, and having to sign let alone notarize an app is a large amount of complexity. Also this app is available on github.

I would like to see examples of how to do this. Apple states that explicit clang modules don't work with C++ interop. ObjC++ has simple interop with C++. Swift does not. And so I'd like to know how to setup my C++ projects to build them as clang modules.

I tried using the GameController APIs for this, but they didn't seem to work. Is that the recommended API for handling keyboard/mouse? The notifications for mouse and keyboard connect/disconnect don't seem to be defined for visionOS. The visionOS 2.0 touts keyboard and mouse support. The simulator can even forward keyboard/mouse to the app. But there don't seem to be any sample code of how to programatically receive either of these. The game controller works fine (on device, not on Simulator).

So I found out clang can do multiarch compiles (-arch arm64 -arch x86_64). But Apple seems to have left precompiled header support out. So I built the pch separately for each arch. That all works. The next problem is that one needs to specify -include-pch foo.x64.pch and -include-pch foo.arm64.pch on the command line. This doesn't work on the compile line, since it tries to prepend arm64 AST to a x64 .o file, and vice versa. So there is -Xarch_arm64 and -Xarch_x86_64 . But that option is limited to one argument. But "-include-pch foo.x64.pch" is two arguments. More details of failed attempts here: https://github.com/llvm/llvm-project/issues/114626 And no splitting out the builds isn't the same, because then -valid_arch I don't think skips the other build. This are all libraries being built by Make, and then the universal app built using an Xcode project from the libraries.

For as long as I've used Xcode, the Issue navigator shows stale errors and warnings even after the build is completely building and executing. It would be nice to have a way to retain file warnings without having to set "warnings as errors", but here the problems have already been fixed. Also need a "Reveal in Report Navigator" since half the time these errors/warnings lack 90% of the info needed to actually fix them. There's already a "Reveal in Project Navigator" that is almost never needed.

Not sure why this has to be so obscure. But somehow adding the call into toggleFullscreen, even though this appDelegate doesn't have a window set, adds a menu item with the fn+F menu item. Posting this to save other pain. Plus the View menu doesn't even have a reference, and is empty otherwise. Pretty hard to polish something shippable with these unfixed outstanding flaws in the API. CommandGroup(after: .toolbar) { // must call through NSWindow Button("See Below") { // Window isn't set in AppDelegate, so menu item is skipped. // But add fn+F menu item into app. Suo many stupid hacks. appDelegate.window?.toggleFullScreen(nil) } }

Xcode 16 breaks fundamental feature of error/warning clickthrough to a given header or .cpp file. The issues list will jump to the point of include, instead of the actual error/warning. There's not even a highlighted line since these files aren't the source of the error. Not really sure how this one got through QA since Apple uses Xcode internally. Now I'm constantly having to scour the report navigator, open the items, and then manually jump to file/line.

There's nowhere to add -mf16c and -mfma that doesn't cause a uinversal build to spew warnings about those settings when it builds arm64. I'd rather not have to add a xcconfig file across every project with an x64 specific setting. So why doesn't the AVX2 setting (-mavx2) also set these flags? -mhaswell does, and so does -mx86-64-...-v3, but those seem to only be supported by clang-cli on Windows.

I typically read an extended gamepad capture() and get all state. But PSVR2 controllers seem to report nothing. So the stick and other buttons don't do anything in a built app. They register as left/right controllers. This on vOS 26, Xcode 26, etc. They work correctly in the main icon view, although they don't honor inverted vertical and horiztonal scrolling. Both of the default scrolls just feel wrong. When I move left I'm want to scroll level not right. Same for up/down.

To minimize uptime, I am currently using two command buffers. One holds offscreen commands and is then committed. Then the second waits 20-30ms under heavy gpu use on nextDrawable, does a little work, and calls presentDrawable(which is drawable.present in addScheduledHandler). This whole setup seems less than ideal. On Android, Vulkan stalls very little on vkImageAquire, and mostly on vkQueuePresent, but that is after the command buffer is ended and submitted. Doing that present call on a thread is often suggested, but the command buffer is already complete and submitted to the gpu before that call. Metal stalls the commit of the command buffer from this fundamental architecture limitation. I would prefer to have a single command buffer here. The nextDrawable especially with frontBufferOnly set is really just a reference to a drawable, and shouldn't lead to such a long stall. This also makes using double buffering nearly impossible.

This seems to defeat the purpose of a developer forum, if no one can respond to posts except for Apple. Some of my posts are less than 1 month old? Even I don't check the forums that often, but it would be nice to respond to people's questions that have accumulated.

The macOS screen recording tool doesn't appear to support recording HDR content (f.e. in QuickTime player). This tool can record from the camera using various YCbCr 422 and 420 formats needed for HVEC and ProRes HDR10 recording, but doesn't offer any options for screen recording HDR. So that leaves in-game screen recording with AVFoundation. Without any YCbCr formats exposed in Metal api, how do we use CVPixelBuffer with Metal, and then send these formats off to the video codes directly? Can we send Rec2020 RGB10A2Unorm data directly? I'd like the fewest conversions possible.

CMake calls through to xcodebuild clean, but this fails since custom build directories are set. The current workaround is to have to trash the entire CMake build folder. With many subprojects this then takes a long time to rebuild. Can Apple please fix this? Here I have a project with multiple targets (a fake workspace). CMake can only generate xcprojects and not xcworkspace files. Visual Studio and Android Studio both integrate CMake into the IDE. But building iOS and macOS universal apps is still not simple with CMake. Can Xcode team support CMake better in general? cmake --build . --target clean  xcodebuild -project foo.xcodeproj clean -target ALL_BUILD -parallelizeTargets -configuration Debug -hideShellScriptEnvironment Command line invocation:   xcodebuild -project foo.xcodeproj clean -target ALL_BUILD -parallelizeTargets -configuration Debug -hideShellScriptEnvironment User defaults from command line:   HideShellScriptEnvironment = YES note: Using new build system note: Building targets in parallel error: Could not delete `build/lib` because it was not created by the build system. error: Could not delete `build/app1` because it was not created by the build system. error: Could not delete `build/app2` because it was not created by the build system. warning: Refusing to delete `build` because it contains one of the projects in this workspace: `build/foo.xcodeproj`. CLEAN FAILED