This must be a bug in NSTableView, but when I hide the view, the NSScroller shows its scrollbar moving through an empty list and still responds to vertical gestures. Since this is over a view that already handles panning, this causes a giant deadzone where the table was displayed and vertical panning stops on that section of the view because the table view is intercepting it. All I do is supply an NSTableViewDelegate. The autohide property is set on the scrollers. This should not be responding to gestures either.

There was a good 2021 WWDC presentation on using ProMotion on iOS, and using Adaptive Sync (ProMotion) on macOS. But while the macOS presentation showed how to detect ProMotion (fullscreen + min/maxInterval mismatch). The iOS side doesn't have this same mechanism. The talk mentions Metal sample code for the talk, but I don't see ProMotion mentioned anywhere in the Metal samples when I do search. https://developer.apple.com/videos/play/wwdc2021/10147/

Visual Studio, Stadia, and JetBrains are supporting natvis files, where Xcode is still stuck on lldb python files that even Xcode no longer uses to debug data structures. Apple has converted all of their scripts to native code, so there are no samples of how to write complex lldb visualizer rules. There is already an lldb-eval that can bring in natvis files, so something like this should be brought to Xcode. C++ packages like EASTL only ship with a natvis file, and it's far simpler to edit and write than the lldb rules and python scripting.

I have this game controller connected to my M1, and the Simulator won't announced it via .GCControllerDidConnect. This works fine on iOS and macOS. I have the simulator set to "Send Game Controller to Device" which the Simulator does. If I disable that, then I can control the simulator view. But once enabled, the Simulator doesn't tell the app about the controller.

This has been broken for over 5 years now. I see 2 different behaviors in 2 different SwiftUI apps. This makes SwiftUI not ready for prime time apps, but I just have tools right now. The VStack { List } doesn't scroll to the item in a long list. The selection moves to the next item in the list, but can't see it. This is just basic UI functionality of a list. UIListView doesn't have this issue. The NavigationView { List { NavigationLink }} wraps around back to the top of the list when pressing down arrow past the last visible item, but there are plenty more list items to visit.

I'm getting "Bad Message 431" trying to access the forums from Chrome, so I'm using Safari instead. This is a thread with a ton of people hitting this problem. https://developer.apple.com/forums/thread/123657 I tracked it down to a bug in the validation layer. This happens with Apple's own sample code. RG16Unorm and other formats shouldn't be flagged as unsupported on a RDNA1 chip in the 16" MBP. Please also make are R16Unorm isn't flagged either. The Metal texture loader used in the sample seems to always pick the wrong format for loaded images (RG for a height map png?), with no way to control the format. This is the feedback assistant post on it. https://feedbackassistant.apple.com/feedback/9540775

I'm trying to update all my projects to C++20. The C++ only projects work fine. All the Objective-C++ files, though, suddenly stop compiling. Is this supposed to work. I can't imagine [NSString stringWithUTF8String:foo] should be failing. Setting the project back to C++17 works. I do have -fmodules and -fcxx-modules for clang modules in some projects. Do those all need to be removed for C++20 modules?

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.

Does this setup seem correct to get precompiled headers? When I look at the file compile times they're way too long, like it's not using the pch. App.pch file, I set #include "MyConfig.h" Then in Build Settings: GCC_PREFIX_HEADER = pathto/App.pch GCC_PRECOMPILE_PREFIX_HEADER = YES Force include of a header. This avoids needing to include the header first in every file. -include MyConfig.h or should it be? -include App.pch

I see region support in MTLBuffer to MTLTexture upload calls, but I’d like to upload an entire level of same-sized mips in 1 call. Calling these routines once for every image x 2048 layers x every mip is a lot of commands. If I could do this once for each mip size, that seems more efficient, though a longer command for Metal to complete.

I have MSL .metal files generated by a parser that go into a blue reference folder. Xcode barely highlights "half" and "return" in purple and nothing else. .metal files that are included in project have blue and other highlights. It's also quite limiting that VSCode has hlsl and a metal plugin, but Xcode doesn't syntax highlight my source HLSL files that I generate the .metal files from. This is quite common to go from HLSL or spirv back to MSL, since there is no path from MSL to spriv.

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 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.

Since this api requires &__dso_handle instead of the standard file/line/func, I had to modify my entire log system to pass this down from the macro call sites. I have many callbacks that typically just forward data from other C++ libraries that never supply a dso_handle. so it's great how this logging system breaks most logger systems and doesn't have a warning level to match fault/error. I have the forwarded threadName, timestamp, etc and no where to store that in os_log. syslog was more powerful and clear than os_log, but I'm sure it's now too late to head down a more reasonable path.. So I pass the &__dso_handle all the way to the log command and hand it into the macro #define my_os_log_with_type(dso, log, type, format, ...) __extension__({ \ os_log_t _log_tmp = (log); \ os_log_type_t _type_tmp = (type); \ if (os_log_type_enabled(_log_tmp, _type_tmp)) { \ OS_LOG_CALL_WITH_FORMAT(_os_log_impl, \ ((void*)dso, _log_tmp, _type_tmp), format, ##__VA_ARGS__); \ } \ }) Logger.mm // This doesn't work, logging the dso from the callsite. No file/line. my_os_log_with_type(entry.dso, os_log_create( "com.foo", entry.tag), logLevel(entry.level)), "%{public}s", text ); // This does work, but who wants to jump to the forwarding log implementation? os_log_with_type(os_log_create( "com.foo", entry.tag), logLevel(entry.level)), "%{public}s", text );