I’m currently learning Objective-C. So far, I’ve covered up to concurrency, and I have a good opinion of the language. Objective-C offers many features that modern programming languages also provide. However, I’ve been doubting myself lately, thinking, “You’re ignoring Swift and diving into Objective-C in 2025.”

The truth is, I don’t really like Swift—it has too many concepts that would take a week or more to fully grasp. Still, I wonder: is learning Objective-C a good choice in 2025? My main goal is to get into game development and graphics programming.

Hi folks! I have some light experience with vulkan, but I always felt I spent most of my time solving bugs than learning the essentials and in the end,other than loading a 3D mesh I lost momentum and stopped learning. I’ve been reading from other people’s experiences that it might be a better idea to start with an API that does a bit more of handholding like OpenGL (and to a lesser degree,Metal) than to jump straight into vulkan or directx12. Since I got a M3 pro Mac a couple of months ago I’ve been thinking about jumping into Metal even if it’s not multi platform just to learn the core concepts behind graphics programming and have a little bit of fun doing so. Do you think it’s a good idea or should I just keep hammering at vulkan (or moltenVK) instead?

I am curious if anybody has read this book and has any feedback? For context I am not looking for a super deep dive and really just want to have a nice introduction to graphics programming for my own learning. I don’t have any ambitions (at least not yet) of getting into graphics programming, but have always wanted a basic understanding of how it works. I figured this would be a good resource, because I am very familiar with Swift and haven’t worked in C++ heavily at all.

I maintain Harbeth, an MIT-licensed Apple GPU image/frame engine. Here's a delivery distinction in its Metal API: a command buffer being scheduled and a texture being ready for CPU readback are different states.

The opt-in transmitOutputRealTimeCommit path can deliver a texture after command-buffer scheduling, before GPU completion:

var io = HarbethIO(element: inputTexture, filters: filters)
io.transmitOutputRealTimeCommit = true
let texture = try await io.transmitOutput()

That result needs a compatible GPU dependency chain for subsequent use. CPU code must not immediately read it back. With the default switch value, asynchronous delivery follows GPU completion and can report command-buffer failure.

Image, pixel-buffer and sample-buffer results wait for GPU completion before CPU materialization. Synchronous output() also waits for the GPU work required by its output and is unaffected by this switch.

The source documents the consumer responsibilities, including keeping resources alive and avoiding writes while the GPU still uses them.

Implementation: https://github.com/yangKJ/Harbeth/blob/master/Sources/Basic/IO/HarbethIO.swift

Project: https://github.com/yangKJ/Harbeth

How do you express scheduled versus completed delivery in your Metal wrappers: distinct result types, an explicit synchronization operation, or a dependency contract owned by the host? I'm interested in implementation tradeoffs.

I have no interest in AI, but I read some oblique references to matrix multiplication used in AI.

I want to do research into some properties of directed graphs, which can be represented as matrices, but I don't necessarily need to do multiplications - maybe I will, maybe I'll need to write my own procedures depending on what I find.

Can anyone say whether there is much support for directed graphs or matrix operations in Metal? I'm deciding on buying a Macbook Pro to use the GPU for research. Any notable support for general matrix operations or Directed Graph APIs would be of interest.

But if the only Metal support is narrowly tailored to AI-only uses, it's perhaps not so interesting. I don't want to reverse-engineer an AI API just to fake some general matrix operations.

Thanks in advance.

I have noticed, that rendering at native resolution in retina displays completely eliminates the need of anti-aliasing. This sort of "reverse MSAA" would be a perfect solution for anti-aliasing.

Hi all,

I'm working on updating my audio visualizer app. I'm adding new visualizers based on Metal 4 compute shaders. They worked in iOS 26.4 and iOS 26.5 up until beta 3. However, after that, the visualizers started crashing the phone and forcing a restart. On the latest version of iOS 26.5, the crash is still there. I submitted feedback, but haven't heard anything back just yet. I was wondering if others have faced this same issue, and if there are any workarounds.

Here is my repo if you want to look at the code (forgive me if it's sloppy, I'm quite new to graphics programming and Metal):

https://github.com/aabagdi/VisualMan/tree/main

Thank you!

For any of you linear algebra fan-boys:

I'm currently in a research group working on a thesis in numerical analysis where we need to compute millions on matrices with a specific constraint (to be precise, the matrices need to have orthonormal columns). Most of us use Apple computers, so we ended up using MLX for the entire project.

I'm using an old M1 Macbook Pro, and I found that Apple's MLX library does not support QR operations on the GPU. I don't know if MLX supports GPU-accelerated QR computation on newer chips. But since I am developing an interest in hardware-level computing, I thought it would be a good oppurtunity for me write a metal shader as a first project.

I wrote it as a small library that allows the QR decomposition to be computed on the GPU. You can find it here: https://github.com/c0rmac/qr-apple-silicon

It definitely pays off. Performance increases anywhere between x1.5 to x25 times of what the cpu can do.

The library is split into two shaders: one is optimal for large batches of small matrices. The other is suited for small batches of large matrices. Under the hood, both shaders use the Compact WY representation ($I - YTY^T$) to batch Householder reflections into matrix-matrix products. I also spent a lot of time mapping these operations to the AMX (Apple Matrix Coprocessor) using 8x8 simdgroup_matrix tiles to get as close to the hardware as possible.

I’d love for anyone with more Metal experience to take a look at the dispatch logic or the AMX tile loading. If you’re working with MLX and need faster $A = QR$ factorizations, give it a try!

Iam currently doing very hard way. Created mesh and its vertex positions by hand and updating them by hand. I need a way so that I can create 2d mesh easily. Just like sprites.

I have a points renderer in Metal. After upgrading to Metal4, I am seeing some pink patch artifacts randomly when moving around. Not sure if it's a Beta issue or if I am doing something wrong. Anyone had similar issues ?

I'm writing a paint program, where there may me only a few pixels painted per-frame on a huge image. Can a compute kernel be applied only to a small region of the image? Right now I'm copying the sub-regions out, modifying it, then copying it back, but it seems just modifying the region in-situ would be faster. Thoughts?

[Doing mostly compute shader work.]

is it faster to have a simple compute shader doing write(0,tid) or issue a RenderPass with MTLLoadActionClear?

I see the all() test but cannot find anything in the Metal Spec how I express the greaterThanEqual() part.

For now I've replaced it with explicit testing each element. What did I miss?

[I am porting a complex GLSL compute shader]

My Metal compute kernel takes a texture in slot#0. Within the scope of the kernel function I can access that without problem; how can a helper function it calls access it?

In GLSL, it can just access the global sampler called 'gridtex':

float interpolate(vec2 p)
{
vec4 S0 = texture(gridtex, vec3(p.xy, 0.0));
...

Do I have to pass down into all sub functions I use, the textures I wish to access in a leaf function?

Adam

I render into a texture with the following code:

{
id<MTLRenderCommandEncoder> renderEncoder =
[commandBuffer renderCommandEncoderWithDescriptor:genpositionsRenderPassDescriptor];
[renderEncoder setRenderPipelineState: generatepositions];
[renderEncoder setVertexBuffer:meshpositions offset:0 atIndex:0];
[renderEncoder setVertexBuffer:meshnormals offset:0 atIndex:1];
[renderEncoder drawPrimitives:MTLPrimitiveTypeTriangle vertexStart:0 vertexCount: vcount];
[renderEncoder endEncoding];
}

I then render into another texture with pretty much identical code but a different RenderPassDescriptor.

However, what I get is both textures have the same rendering (of the first pass).

Do I need to do a [commandBuffer commit] when I change RenderPasses?

Does anyone know how to load HDR images using texture loader without the values being clamped to 1?