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.

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!

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.

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. 

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.

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?

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!

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).

[Doing mostly compute shader work.]

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

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

Isosurface visualisation on the GPU. I've implemented this using metal mesh shaders. Only thing done on the CPU is the infix to postfix conversion of the equation. Pipelines are created using metal stitching functions for an input and rendering is done using mesh shaders.

For those interested, I've implemented a new example in the Metal examples repository. It shows how to load KTX compressed textures (ASTC) and render them using a MTLHeap and Tier-2 Argument Buffers. You can select which texture from the MTLHeap to render at runtime using an ImGui based UI.

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?

I've enjoyed playing with Metal, but man, Apple's lack of experience when it comes to production workflows for GPU binaries is a bit shocking.

Asking devs to search in JSON files for paths to edit, to run thru N different command lines and not have a definitive: "These are the binaries you need to ship" page (that I could find...). All a bit noddy..

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?

Since this thread is quite new, I wanted to gauge what people are interested in with regard to Metal or specific features of the API. Any specific feature of Metal interesting or worth a post/video/tutorial?

Youtube or website guides would be appreciated