metal-rs: Metal bindings that upstream asks you to stop using

The deprecation notice is the first thing in the documentation

The project opens with a warning that changes how you should read everything else. Use of this crate is deprecated, because the objc ecosystem of mac system bindings is unmaintained. For new development, the recommendation is to use objc2 and objc2-metal instead.

The commitment that follows is narrower and more useful: basic pull requests will continue to be merged and things will be kept maintained, at least as long as it takes to migrate wgpu to the objc2 ecosystem, with the tracking work pointed at PR 5641 in the wgpu repository.

So the deprecation has a condition and an end state. It is not abandonment, and it is not open ended either. The condition is wgpu's migration, and until that lands, a Metal codebase in Rust that has already chosen this crate keeps working with community fixes.

The date on that last push is 2026-10-13, and the repository is not archived. The release history shows v0.33.0 on 2025-12-17, then v0.32.0 and v0.31.0 both on 2025-04-24. The crate is published on crates.io under the name metal, with the package description Rust bindings for Metal and the homepage pointing at the GitHub repository.

The licence is the permissive dual option, MIT OR Apache-2.0 at your option, and the manifest declares exactly that with edition 2021 and a minimum Rust version of 1.82.

The dependency on objc 0.2.4 is the whole problem

The bindings for Metal are unsafe Rust, and the mechanism underneath them is the objc crate. The manifest pins the dependency at version 0.2.4 of objc, and that is the crate the project names as unmaintained.

This matters because Metal is an Objective-C API. Any Rust binding to it has to cross into the Objective-C runtime somehow, and this one does it through a crate that no longer has maintainers behind it. The deprecation is therefore not a judgement about Metal, and not about the quality of the binding layer, it is a statement about the health of one dependency underneath it.

The rest of the dependency list shows what a Metal binding needs beyond the runtime bridge. core-graphics-types at 0.2.0 supplies the shared CoreGraphics types, with the link feature enabled by default so those types link against the system framework rather than being re-implemented. bitflags 2 handles the many flag enums the API is built from, log 0.4 provides the logging, block 0.1.6 and foreign-types 0.5 cover the Objective-C block and foreign type conventions, paste 1 is used for macro generation, and dispatch is an optional dependency for the Grand Central Dispatch types.

The feature set is small and deliberate. The default features are link, which turns on the core-graphics-types link. There is mps for the Metal Performance Shaders family, private for internals, and a cargo-clippy feature that exists as a workaround for a clippy issue recorded in the pull request 344 discussion.

The dev dependencies tell you about the test surface: cocoa 0.27 and winit 0.29 for the windowed examples, png 0.18 for image output, glam 0.33 for the maths, rand 0.9, and sema 0.1.4.

The examples directory is where the API is actually explained

The documentation points at the examples directory and says it highlights different ways of using the Metal graphics API for rendering and computation. Reading the example list is the fastest way to understand the scope of the crate, because it names the areas of Metal it reaches.

There are seventeen of them, and the coverage is broad: argument-buffer, bind, bindless, caps, circle, compute, events, fence, headless-render, library, mesh-shader, mps, raytracing, reflection, shader-dylib, texture and window.

A few of those names tell you what the crate is for. headless-render is the one that matters for automation, because it renders without a window, which is what you want in a test or a build server. caps is about querying device capabilities, events and fence are the synchronisation primitives, argument-buffer and bindless cover the modern buffer binding models, and mesh-shader and raytracing cover the newer GPU features.

Running one is a single cargo command, with the example name substituted for the one shown:

# Replace `window` with the name of the example that you would like to run
cargo run --example window

The Cargo manifest also registers several of them explicitly, which is where you see the details: the mps example carries required-features = ["mps"], so it only builds when the mps feature is on, and the circle, compute and embedded-lib examples point at specific source paths such as examples/circle/main.rs and examples/compute/embedded-lib.rs rather than the default layout.

The Makefile turns .metal sources into .metallib files

Metal shaders are written in a separate language and compiled by a toolchain that comes with the Apple developer tools, and the Makefile in the repository root wires that into the examples.

Each target compiles a .metal file to an intermediate .air file and then links it into a .metallib. The compute target, for instance, runs xcrun -sdk macosx metal -c examples/compute/shaders.metal -o examples/compute/shaders.air and then xcrun -sdk macosx metallib on that output to produce examples/compute/shaders.metallib. The window, circle and raytracing targets follow the same shape, and the raytracing one adds the -g flag when compiling.

The xcrun wrapper is the part worth noting. It selects the SDK for you, so the commands work against the toolchain installed on the machine rather than a path you have to track yourself. In practice this means the shader build step depends on the Xcode command line tools being present, which is the practical constraint when the crate is used in CI.

The result is that a working Metal setup has two halves that are compiled by different tools: the Rust side with cargo, and the shader side with the Apple shader compiler through make. The Cargo manifest even excludes examples/texture from the published package, and the guide directory is excluded as well, so the published crate is the library plus the example sources, not the full development tree.

What migrating to objc2-metal actually involves

The alternative is named in the deprecation notice itself, and it is not another Metal binding crate but a different foundation. objc2 and objc2-metal are the crates the project points new development at, and the reason is the same one that caused the deprecation: they sit on a maintained Objective-C runtime layer rather than on the unmaintained objc crate.

The difference in approach is about the dependency underneath rather than the graphics API on top. If you are starting a new Metal project in Rust, you are choosing which Objective-C bridge to build on, and the project has told you which one it considers maintainable. Your Metal code, your shaders and your rendering architecture stay the same either way; what changes is the layer that talks to the Objective-C runtime.

The wgpu connection matters for a second reason. wgpu is the abstraction that many Rust graphics projects use, and PR 5641 in the wgpu repository is the migration work to the objc2 ecosystem. Until that lands, wgpu itself still needs this layer, and that is the stated reason for continuing to merge basic pull requests here. The end state is a wgpu that no longer depends on the unmaintained objc crate, at which point the maintenance commitment described in the warning lapses.

For an existing codebase, this is a scheduled piece of work rather than an emergency. For a new one, the choice has effectively been made for you, and picking metal-rs means taking on a migration you have not started.

Licence, contribution terms and what remains after the warning

The licensing is straightforward. The crate is licensed under either of the Apache License, Version 2.0, or the MIT license, at your option, with the two licence files in the repository root as LICENSE-APACHE and LICENSE-MIT. The contribution rule matches: unless a contributor states otherwise, any contribution intentionally submitted for inclusion is dual licensed under those same terms, with no additional conditions.

The documentation on docs.rs is built for a specific set of targets, and the list in the manifest is a good signal for who the crate is for: aarch64-apple-darwin, aarch64-apple-ios, aarch64-apple-ios-sim, x86_64-apple-darwin and x86_64-apple-ios. The aarch64 Apple silicon target is deliberately presented first on docs.rs, which tells you where the traffic is.

The repository layout is small and conventional for a Rust crate: Cargo.toml and Cargo.lock at the root, a Makefile for the shader targets, src/ for the bindings, examples/ for the sample programs, guide/ for the written guide, assets/ for images, a .cargo/ directory for cargo configuration, and renovate.json for dependency updates.

The last push was on 2026-10-13 and the repository is not archived, so the crate is not frozen. It is simply not where new work is meant to start, and the documentation says so in the first block of text, above the badges and before the description of the examples.

Editorial conclusion

Adopt metal-rs only for an existing Rust Metal codebase that has not yet moved to objc2, since the project will keep merging basic pull requests until wgpu migrates and the crate still carries a working example set covering compute, raytracing and headless rendering. Do not start new Metal work on it, because the warning at the top of the documentation points new development at objc2 and objc2-metal, and the underlying objc crate is unmaintained. Verify first that your Rust toolchain is at least 1.82, that the crate version you pin matches your Apple SDK, and that the objc2 migration path in wgpu PR 5641 is not already available to you.

Frequently asked questions

Official sources

1. gfx-rs/metal-rs on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases