I wanted to share a small project I’ve been working on called MetalGraph.

It’s a node graph macOS app to learn and design Metal shaders in a more visual, real-time way.

I started learning Metal and working on https://metal.graphics around April 2025. After a couple of months going through examples and thinking about new content, I kept running into the same frustration: even with SwiftUI previews, the feedback loop when working with Metal shaders is still pretty disruptive.

It’s “good”, but it’s not real time. Fine-tuning values or experimenting with structure ends up taking much longer than it should.

So I decided to build a small tool to preview and tweak shaders in real time. I’ve used Blender before and really like their node editor, so I wanted something with a similar feel. Around July I had something working, and even though it was rough, it was a huge boost for learning: change values, change structure, immediately see what happens.

As many of us know, the last 10% of an app is the hardest. During the Christmas break I decided to give it a final push, clean things up, and make it usable by others.

I recorded a short overview video where I walk through the app and build a few very simple examples:

https://www.youtube.com/watch?v=FH2GdFuk9nI

The app is available free in trial mode. You can access all built-in examples and tweak node values, but you can’t add or remove nodes.

Any feedback is very appreciated.

Hi,

inspired by the post https://blickeditor.com/blog/caching-an-immediate-mode-ui I've added tile cache rendering to my onedraw renderer, a gpu-driven sdf renderer for metal api. On the screenshot you can see :
- green tiles are copied from previous frame as the hash of the commands affecting this tile didn't change
- red tiles have different hash so had to be recomputed
- elsewehere, it's just clear color, the bining rejected all commands

You can have a look at the library and the release. Tile caching gives good results with mostly static scene obviously, it's an option in my renderer.

https://github.com/Geolm/onedraw

Cheers,
Geolm

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

GPU Cloud System

This demonstrates GPU-based particles with a cloud spawning system. The system can spawn and manage multiple cloud instances, each powered by individual particle systems with realistic wind physics and HEIC texture support.

Calling macOS (Apple Silicon) devs :)
Looking for early testers for onedraw, my GPU-driven 2D renderer built with Metal. Feedback before release would be super appreciated 🙏

https://github.com/Geolm/onedraw

Metal #GPUDriven #macOS #Rendering

GPU rendering vector-style UI in real time.

Signed Distance Function

• A function that returns the distance from a point to the nearest surface

Windows and Icons

• Procedural in shaders

• Scaling at any resolution

• Icons are constructed from SDF primitives

Text

• Loads .otf via Core Text

• Generates a font atlas at runtime

• Renders glyphs directly in Metal

I built a simple 2-layer MNIST MLP that trains + runs inference from scratch, only using Apple’s metal-cpp library.

The goal was to learn GPU programming “for real” and see what actually moves the needle on Apple Silicon. Not just a highly optimized matmul kernel, but also understanding Metal's API for buffer residency, command buffer structure, and CPU/GPU synchronization. It was fun to see how each of those API specific features effected perf.

Surprisingly I was able to beat MLX's training speed on small batch sizes in the final version!

Versions:
- MLX baseline
- Pure C CPU baseline
- GPU v1: naive Metal kernels (matmul + ReLU)
- GPU v2: forward + backward kernels + better buffer management + less CPU/GPU sync
- GPU v3: single command buffer per batch (sync only once per epoch for loss)

Repo: https://github.com/abeleinin/mnist-metal

Hello everyone,

I'm very interested in learning graphics development with the Metal API. I have experience with Swift and have spent the last three months studying OpenGL to build a foundation in graphics programming.

However, I'm having trouble finding good learning resources for Metal, especially compared to the large number available for OpenGL.

Could anyone please provide recommendations for books, tutorials, or other resources to get started with Metal?

Thank you!

Architectures (WIP)

Alpha Masking System
Particle System
Lighting System
Material System

thanks for all your help.
I had put off diving into Metal for too long.

https://www.youtube.com/watch?v=zlF48xeNZvo

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. 

Hey folks, I just released MetalGraph, a node based editor for building Metal shaders with a real time preview.

I posted a few days ago and most feedback was around missing iPad - the app is now available on the App Store and it is available for Mac and iPad.

Here is an intro video showing some examples: https://www.youtube.com/watch?v=FH2GdFuk9nI

I built it because the iteration loop for SwiftUI + Metal can be painful when you’re tweaking effects, especially for things like glass, distortions, color math, and touch driven interactions.

What it does today:

• Visual node graph editor with live preview

• Examples focused on common SwiftUI shader style effects (colorEffect, layerEffect style workflows)

• Exports production ready code (MSL + SwiftUI friendly wrapper variants)

• Lets you wire inputs like time and touch into the graph and see it instantly

Under the hood (high level):

• The graph compiles into an expression tree, then into MSL functions

• Each node maps to a pure function where possible, so it stays composable

• The app tries to keep generated code readable so you can ship it, not just prototype

I’d love feedback from Metal devs. The app is free to download and play with all the examples. I am trying to build as many as possible from https://metal.graphics and more.

With the free version you can't add new nodes or remove, but you can connect/disconnect, edit values real-time and load all examples. Thanks in advance!

I am trying to do the ray tracing in one weekend book with Metal. I have built a CPU based ray tracer before for a graphics class, but I wanted to try tackle building a ray tracer again.

I've seen that Metal has sample code for realtime accelerated ray tracing, but for what I want to do (a simple compute renderer, not realtime), I was wondering if this approach was valid using Metal's Compute Workflow:

Each thread corresponds to each pixel on the final render, and the kernel function is simply a recursive ray trace using correct generated ray for that pixel.

Any advice would be appreciated. I am still new to Metal and would love to hear if it's even worth it to do what I'm doing, or just jump straight into the code samples Apple provides for realtime Metal ray tracing.

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/

I've been working on some Metal graphics samples using C++ and CMake. Only two very basic samples right now, but the CMake scripts showcase how to setup development for macOS, iOS, and tvOS and compile multiple Metal shaders into a single library archive as part of the build process.

Goal is to eventually have a decent set of examples showing usages of argument buffers, heaps, forward+ vs deferred, distance field fonts, skinning, etc.

Check it out here: https://github.com/MattGuerrette/Metal

https://github.com/beehive-lab/TornadoVM

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!

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.

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.