When you use the simd classes like float3/matrix3x3 on Swift they are great. I can write and run code like this from existing math routines that are readily found on the web. let value = m[0][0] * v[0] When you try to do this in C++/ObjC, the code becomes this. This is not code readily found on the web, and is a big pain to convert. float value = m.columns[0][0] * v[0]; Can the float3x3 and other wrappers to simd_float3x3 provide an operator[] to the column and other operations like splatting since v[0] above pulls the data out of simd registers. We currently have to derive off the matrix classes, but it seems like functionality that should be provided in the C/C++ simd classes. A vector math library should promote better code readability than this. We seem to not be able to derive off the vector types which is an issue below. I also have code based on classes that takes 3 elements that suddenly has to convert to this less readble form. float3 v(x,y,z) - float3 v(simd_make_float3(x,y,z)) And then there's this code that should fill all values like init repeating in Swift. This is error prone in converting existing simd code to Accelerate simd. So then we try to wrap the float3, can't derive off them, and then lose all swizzling support, operators, etc. Then have to roll our own ops on that struct that holds a float3. What's the recommended way to make this more C++ like without more compiler support float3 v = {3} - 3,0,0 wasn't expecting that float3 v(3) doesn't compile v = {3,0,0} is completely different syntax, and doesn't line up with MSL and most simd libraries struct myfloat3 : float3 doesn't work struct myfloat3 { float3 v; - works, but loses swizzles, operators, etc explicit myfloat3(float value) myfloat3(float x, float y, float z) ... }

The problem with ClampToEdge is that it stretches the outer strip of pixels even when uv goes outside [0,1]. So the typcial change is to use ClampToZero. The problem with ClampToZero/Border of 0 is that it pulls in black transparent color into images. What would be better is for this to double up the edge pixels of the texture (ClampToEdge), and only once uv exceeds 0,1 then bilerp the transparent color. Currently ClampToZero pulls in black and drops alpha at the edges of small images leading to poor edges of small textures.

Bad Message 431 reason: Request Header Fields Too Large That's the result I get trying click on any forum message from Google Chrome. Safari doesn't exhibit this issue, so please fix the html that drives for forums so that more browsers are supported.

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.

The Adobe C++ plugin SDK are still using Rez to compile resources on macOS and winOS. But Rez build settings are missing from my newly created project. They exist in a legacy project. How does one re-enable this functionality. I don't know that Apple has offered an alternative to file-based resource generation, so removing this functionality seems premature. The help and man pages on Rez are missing a lot. What to supply for arch (x86_64)? Why do I have to supply the framework path to Xcode to find Carbon.r and CoreServices.r? Rez itself provides only the barest of command line usage details. For example, I couldn't get .r includes to work with -i or -s, but it works with -I. But the resulting .rsrc file that is generated by my command line efforts is 0 sized. The one built from Xcode is 1.5KB (correct). Also SIP was blocking all attempts to debug these plugins, but a workaround was found for that.

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.