Actually, I was wrong. The code in my self-reply solves the issue. With the background in black, it's hard to see the partly transparent pixels. I fixed another minor problem where I wasn't able to clear the drawing area to a color other than black, and when I cleared it to black I was able to to see that my texture is now being drawn with proper alpha blending.

I used the ChatGPT feature in Xcode to suggest change to improve my alpha blending, and it suggested I add the following to my MakePipeline function: func makePipeline() { let library = device.makeDefaultLibrary() let pipelineDesc = MTLRenderPipelineDescriptor() pipelineDesc.vertexFunction = library?.makeFunction(name: "vertex_main") pipelineDesc.fragmentFunction = library?.makeFunction(name: "fragment_main") pipelineDesc.colorAttachments[0].pixelFormat = .bgra8Unorm // ---- New changes // Enable blending for transparent drawing pipelineDesc.colorAttachments[0].isBlendingEnabled = true pipelineDesc.colorAttachments[0].rgbBlendOperation = .add pipelineDesc.colorAttachments[0].alphaBlendOperation = .add pipelineDesc.colorAttachments[0].sourceRGBBlendFactor = .sourceAlpha pipelineDesc.colorAttachments[0].destinationRGBBlendFactor = .oneMinusSourceAlpha pipelineDesc.colorAttachments[0].sourceAlphaBlendFactor = .sourceAlpha pipelineDesc.colorAttachments[0].destinationAlphaBlendFactor = .oneMinusSourceAlpha // ---- end of new changes pipeline = try! device.makeRenderPipelineState(descriptor: pipelineDesc) } With those changes the macOS and iOS versions of the app now both show the same image, where every pixel is either fully transparent or fully opaque. It's a step in there right direction but still not what I need.

Excellent. Thanks for that. My work’s build chain isn’t ready for Xcode 26 yet. Is there a solution for Xcode 16.3 and other older versions of Xcode?

@Frameworks Engineer FocusState and AccessibilityFocusState are independent settings, and can be pointing at different views at the same time. Chaning FocusState does seem to work (mostly) correctly to set the focus state to the desired view, but the accessibility focus state doesn't change. (I say mostly because in some cases setting the @FocusState fails and the variable's value is set to nil instead. I haven't figured out what that fail case is yet.) Ignoring the mystery fail case, having the FocusState and AccessibilityFocusState point to different views leads to some odd behavior. If I have the a11y focus set to a button, and that button's action changes the FocusState to a text field, then the text cursor moves to the text field, but the a11y focus stays on the button. In FKA mode, pressing the spacebar triggers the button, which can then change the focus state to a different field. However, typing a character other than a space causes that character to be added to the text field that has the focus state.

Note that I accidentally posted a link to a Stack Overflow question I posted on the issue. I meant to post a link to the Github repo: https://github.com/DuncanMC/SwiftUI_A11y.git

In order to answer we need to talk about ARC, which still exists "under the covers", but is managed by the swift compiler. Some functions return "autoreleased" objects. These are objects with a retain count of 1, but they have been added to an "auto-release pool". An autorelease pool is a list of objects that should be sent a release "soon", where soon usually means the next time your app services the main event loop. If you have a function that creates a very large number of autoreleased objects, your app's memory footprint can grow while the app is running. The objects will get released once the function finishes and your app services the event loop, but in the meantime, they take up memory. This is not a memory leak, but it can increase the total memory footprint of your app. (On modern devices you have to create a LOT of large objects in order for this to be an issue. The days of having less than a megabyte of app memory are long gone.) The autorelease statement creates a local autorelease pool that accumulates objects while the code in braces is executed. Once you leave the scope of the braces, the autorelease pool is "drained". (All the objects get sent a release message, causing them to be deallocated if there are no other strong references to them.) I believe allocating reference objects like class instances is an example of creating an autoreleased object, so your example of a for loop that creates multiple class objects and stores them in a local example would probably be a case where an autorelease pool would keep your app's memory footprint from growing while the for loop runs.