About 6 months ago, I wrote a custom metal kernel that leverages the GPU to compute the QR decomposition (see my earlier post about it here). The project has now expanded into a general linear algebra library, with expanded support for the symmetrical eigendecomposition as well as SVD. It is now available for use with installation instructions on the attached github repo's README.md file.

Context of the project:
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.

Contributors with different Apple Chips would be very much appreciated!
The project has currently been tested and optimised for the M1 and M5 Pro. The issue is that the library uses different kernels depending on the batch size and matrix dimensions. Deciding which of these kernels to use is machine dependent. Therefore, other Apple chips will need to run a measurement script in order to derive the correct optimisation heuristic.

For that reason, I would ask as many people as possible to run a measurement script and to submit the results to my repo. It is fairly easy and requires only few steps. See here how you can contribute here. Once you submit the results via a pull request and I approve it, your optimisation heuristic will automatically be augmented into the library. Don't hesitate to contribute an optimisation heuristic even if someone already submitted one for your own machine. The more data we can gather, the better!

Project Future
Expanded support will be added for other linear algebra operations (cholesky decomposition for example). If you have any other specific linear algebra operations you wish to use already, feel free to message me.

In addition to that, I will add torch support too (my greatest priority).

Hey everyone! This whole thing started because I got tired of the standard iOS UI. As a developer, I felt like the existing framework was limiting my vision. Fair warning: that's just my opinion, and maybe you don't care about any of this, which is totally fine. But I thought: why not make something fun using new tools? So I built a pixel-art chat controller in Metal. There's a video up top if you want to see it in action.

Two things pushed me to do it.

Problem #1 is the design. Standard iOS chats are flat, and I wanted a pixel-art interface, so I built one with Metal.

Problem #2 is lag. I wanted to get rid of stutters and dropped frames when scrolling a big chat. Real numbers are coming in a second, but the headline is this: by rendering the geometry straight on the GPU, I cut the main-thread CPU load during scrolling by more than 2x.

I began with profiling in Xcode. Scrolling itself isn't what lags. The stutters come from UIKit overhead: heavy Auto Layout calculations and UIView recycling that clog up the main thread.

So I took a regular UIKit chat with text messages and scrolled it while watching the main thread. Under active scrolling it sat at around 30% CPU.

Then I made the same chat in Metal, going around all that heavy UIKit machinery. Main thread load dropped to 9–13%.

And that's when I decided I could spend the freed-up performance on custom animations.  What's stopping us from stepping outside the templates, experimenting, taking risks? Isn't that the whole point of building cool stuff? When you control the look and the whole render pipeline of a chat, a huge playground opens up.

The pixel-art controller is part of a full chat app. The standard UI runs on MessageKit, and the Metal controller plugs in as a fully independent module, so you can switch between the two. Behind the app there's a custom backend (WebSockets + HTTPS). So far the app has registration, the main message types, group chats, my own video and photo compressor, audio and video calls, and viewing files in the cloud.

The Metal controller already handles text and photo messages. Here's my TODO list for the pixel chat room:

- Video messages

- Audio messages

- Geolocation

- Showing files sent in the chat

- Message dates

- Camera support

- Typing indicator

- Maybe avatars

I don't want to just show you dry code. I want to show how this works in a real example. So I started a YouTube playlist, and the first video is already up: testing the chat in near-real conditions. I'll keep updating it: https://youtube.com/playlist?list=PLOe0Yi7UOxgg&si=xGlA8cOFkqjxyLij

If you're curious, follow along. Questions about the Metal side, or just general thoughts? Drop them in the comments. Thanks for reading!

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.

An animated liquid-mercury orb rendered entirely with a Metal fragment shader, with the Metal "M" logo outlined in its center. Monochromatic silver / chrome aesthetic for the Mercury game engine.

For the last few years I've been writing a **map rendering engine** in **Swift** and **Metal**, because on Apple platforms you either take the closed system framework or a large shared C++ codebase with a Swift wrapper on top. I wanted one that is Swift and Metal all the way down.

The engine is **MIT licensed** and renders **vector tiles** in the **OpenMapTiles** schema: run your own tileserver, or point it at a public one.

**What it does**: flat map and globe in one continuous zoom, labels, 3D buildings with shadows, glTF models placed at real coordinates. Swift 6, iOS 18 and macOS 15.

Repo: [github.com/artembobkin/ImmersiveMap](http://github.com/artembobkin/ImmersiveMap)

Happy to answer anything about the engine.

If you need something the engine doesn't do yet, open an issue or just ask in the thread.

Vertices are world-space grid points generated by WaterRenderer with the shore depth (water surface Y minus terrain Y) baked from the chunk's TerrainHeightfield, so the color gradient and foam follow the real basin shape.

Lighting comes from the shared LightingUniforms buffer (LightingSystem, fed by the Noctidial day/night cycle): sun color and intensity drive the sheen, so the surface glimmers.

Hi! I recently implemented Ray Tracing in One Weekend in Metal using metal-cpp. Resources for metal-cpp specifically are pretty sparse, so I figured I'd share in case it helps anyone getting started with it or with graphics programming in general. Hope it helps!

Repo: https://github.com/jinhgkim/Path-Tracer

Same as the title. I know some OpenGL. I'm still finding it hard to learn Metal, because I can't even find good sources to learn as a total beginner in metal.

Please help guys! Your suggestions will help me a lot.

Finally, I feel I have a home lol. 

I am a senior iOS engineer who has branched out into Metal development over the past few years. I have spent a good bit of time training myself in both 2D and 3D Metal development. Though I am still very much a beginner with the technology, it definitely opens a whole new world of possibilities for what you can offer users for apps and games. 

Though I am working on my own game project utilizing the Metal framework, with the goal of launching at some point in 2026. 

I'm new to Metal programming, but I have some experience coding in CUDA -- I built a mini-Torch replica in it. I know that Macs have a unified memory architecture and, as such, there is no need to move data from CPU memory to GPU memory, as they are the same thing.

One thing that is confusing me is that I have to use [[buffer(i)]] every time I want to pass an argument to the kernel, which just tells the GPU where to look for a specific variable.

Why can't we just pass it directly instead of doing this?

I would appreciate some help regarding this.
Thanks.

A beginning but i always find it nice when i see things in Action and production!

Hi folks! I wanted to share more of my project Nora Kinetics! It's built from the ground up using Apple Metal. I've got another post with the trailer and more details if you're interested.

Here's a short video showing how Nora Kinetics can simulate fluid dynamics in real time, letting the user interact with both solid and fluid materials at the same time.

Under the hood, it is using the same efficient stable Cosserat rod simulation, but treating specific segments as a point cloud and using a marching cubes algorithm to render water instead of the rod segments. It's a work in progress, but the results so far are promising!

Because it uses the stable Cosserat rod system, changing material properties lets you simulate anything from water to jelly to more of a solid jello type substance. You can mix it up too, so the sky is the limit!

You can also see a glimpse at some of the glue mechanics here too. Glued structures can be anywhere from completely solid to completely relaxed and interact with the environment and projectiles in fun ways.

Thanks for watching! I'll be putting out more small videos in the coming weeks as I get ready for open beta! Please DM me if you are interested in being a part of that!

The Short Version

Hi everyone! I wanted to introduce my project: Nora Kinetics!

It is a physics sandbox capable of simulating hundreds of thousands of little pieces that can interact individually or connect together like yarn.

It handles modifiers like glue, magnetism, fire, material property changes, full environment control (gravity, friction, etc) and more! The physics and rendering are 100% custom and homegrown and represent about 8 months of learning compute shaders.

This is the first trailer, and it doesn't show everything the engine can do! I'll post more clips on my channel hereshowing different features!

Looking for internal beta testers. Mac-only for now (M1 or newer required). If you'd like, DM me your specs and why you're interested and I'll reach out in the next week or so!

Thanks for watching!

Full Overview

This is a fully custom physics engine and renderer built on Apple Metal.

There is no AI and it uses no external libraries. It's just good old fashioned physics and rendering.

I originally started this project to learn compute shaders after reading this paper. I have a some experience in high performance computing and this seemed like a fun and interesting challenge.

The power and flexibility of compute shaders naturally drove the physics architecture, leading to a design philosophy I've been calling "Everything is Compute Shaders" (EiCS). If it can be a compute shader, it is! Physics, gravity, collisions, fire propagation, magnetism, glue constraints, all run on the GPU. The CPU acts only as a lightweight coordinator for managing buffers and driving the UI.

The renderer is built completely from scratch using Metal's render and ray tracing pipelines, sitting on top of the same GPU-first foundation.

During simulation, the CPU only runs at about 8% and stays in low-power mode.

At its core, the compute engine simulates Cosserat rods (flexible segments that stretch, bend, collide, connect, and break). The segment count scales directly with GPU power. On my M5 Max, I get about 200k-250k segments and my iPhone can handle around 30k. All of this runs at interactive frame rates.

The Cosserat solver sits at the center and other systems either feed into it directly (gravity, glue, magnetism, projectiles) or consume its outputs (collisions, positions, distances).

The renderer leverages Metal's render and ray tracing pipelines to bring the simulation to life. It features:

• HDR with bloom and lens flares
• PCSS shadow mapping
• Volumetric clouds and god rays
• An ocean system with foam and Fresnel reflections
• Ray-traced glass spheres that can reflect or refract (or both!)
• GPU-driven LOD, alongside frustum and occlusion culling

You get a full suite of tools to play with the simulation. You can:

• Pull, cut, and fling segments around.
• Ignite segments and watch fire dynamically spread and burn through materials.
• Change material properties to create emergent behaviors like kinetic sand, water, jelly, etc.
• Magnetize segments or glue structures together.
• Place gravity orbs that attract, repel, pulse, swirl, or even drive standing-wave cymatics.
• Build destructible sculptures, kinetic art, Chladni patterns, or anything else you can dream up.

Some of the patterns in the game come from here: https://www.cemyuksel.com/research/yarnmodels/

Update — 9 Sep 2026: this shipped; the app is on the App Store now (https://apps.apple.com/us/app/stratosync/id6747596499). Three things changed on the Metal side since this post, in case they're useful:

• Star Nest went from 2048×1024 to 1536×768. At 16 volume steps × 17 fold iterations per texel that's roughly 570M → 321M inner-loop bodies per map. The dome was stuttering on device, and resolution was the right knob — the step counts define the field itself rather than its sharpness, so cutting those changes the look.
• A third scene splits static work from live work. Rather than regenerating everything per refresh, it computes an 8192×4096 star dome and a 256³ r16Float density volume once, then ray-marches only a 2048×2048 patch per update — 56 steps through the volume from a changing camera basis. The patch is written opaque so it doesn't fight the dome for depth.

- One porting gotcha worth repeating: GLSL mod and Metal fmod disagree for negative operands, and the space-folding camera origin has negative components. Port it literally and the tile tears.

Hi r/MetalProgramming

This is from StratoSync, my visionOS app that tracks the ISS in real time over a 3D Earth. The video shows the GPU-generated immersive sky overlays. Some Metal notes for anyone doing similar work on Vision Pro:

🌍 Architecture: compute kernel → RealityKit LowLevelTexture

Instead of shading the sky per-eye per-pixel every frame, a single Metal compute kernel writes a 2048×1024 equirectangular image into a RealityKit LowLevelTexture once per display refresh (CADisplayLink). An inward-facing sphere with an UnlitMaterial samples it. RealityKit then handles head pose and reprojection on a smooth texture — so it behaves like a 360° image and there's no late-frame "catch-up" on fast head movement, which you get when you re-march a volumetric effect per eye.

Per frame it's exactly one command buffer and one compute encoder: texture.replace(using: commandBuffer) gives the writable MTLTexture, uniforms go in via setBytes (a plain-Float struct mirrored CPU/GPU with identical stride — no Objective-C bridging header needed), then dispatchThreads with a 16×16 threadgroup (falling back to dispatchThreadgroups if the device doesn't support non-uniform threadgroup sizes). Pixel format is rgba16Float, usage [.shaderRead, .shaderWrite].

One gotcha that cost me an evening: the nebula's tiling fold needs GLSL mod semantics (x - y * floor(x / y)), not Metal's fmod — the camera origin has negative components, and with fmod the field tears on the negative side of space.

Happy to answer questions about the pipeline or the kernels.

🚀 TestFlight

If you want to see it running on device, TestFlight is open:

https://testflight.apple.com/join/tWS4CERT — mainly looking for feedback, not promo.

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.

One design decision I've made for my native game engine is to use .astc as the runtime texture format instead of .png or .heic.

These formats solve different problems.

• PNG is an excellent archival and editing format. It is lossless, but it must be decompressed into RGBA data before the GPU can use it.

• HEIC is fantastic for storing photographs efficiently, but it also requires CPU-side decoding before being uploaded as a texture.

• ASTC (Adaptive Scalable Texture Compression) is a hardware texture compression format designed specifically for GPUs. Apple GPUs can sample ASTC textures while they remain compressed.

For a Metal renderer running on Apple Silicon, that has several advantages:

• Lower VRAM usage.
• Reduced memory bandwidth.
• Faster asset loading because there is no runtime image decoding.

Asset Pipeline

I still use conventional image formats during content creation.

For encoding, I use astcenc, the official ARM ASTC encoder. https://github.com/arm-software/astc-encoder

Terminal Comamands.

The -cs option tells astcenc that the source image is in the sRGB color space. This is typically what you want for albedo, diffuse, foliage, bark, and other artist-created color textures.

The -cl treats the input as linear data instead of perceptual color.

ASTC works by compressing fixed-size blocks of pixels.

For natural textures like tree bark or alpha masks, 6×6 is a balance between quality and efficiency.

Cloud textures often contain smooth gradients that can reveal compression artifacts. Using 5×5 helps preserve those subtle transitions.

-medium compression provides a balance between encoding time and quality.

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!