MoltenVK (Vulkan on Metal) was deprecated in favor of KosmicKrisp
3 points · Open discussionKhronosGroup
MoltenVK
Objective-C++2018–2026
KhronosGroup / MoltenVK
MoltenVK
MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vulkan applications to run on macOS, iOS and tvOS.
56Distinct people
57Mentions
0Explicit recommenders
5.9KGitHub stars
What to know before exploring
What it is
MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vulkan applications to run on macOS, iOS and tvOS.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- gfx-rs/gfx · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year57 dated mentions
Observed mentions: 2018-04-04 13:43:17 UTC to 2026-10-25 12:08:41 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 1 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
CautionDeprecation notice: Khronos has deprecated MoltenVK, its Vulkan-on-Metal implementation. This repository is now maintained by the community on a best-effort basis.
For Vulkan on Metal, Khronos now recommends KosmicKrisp on Apple Silicon Macs. MoltenVK remains the recommended option for Intel-based Macs and for iOS.
You can get KosmicKrisp in either of two ways:
Install the latest macOS Vulkan SDK from vulkan.lunarg.com.
Build the KosmicKrisp driver from the Mesa project source.
MoltenVK
Copyright (c) 2015-2026 The Brenwill Workshop Ltd.
Table of Contents
Introduction to MoltenVK
Developing Vulkan Applications on macOS, iOS, tvOS, and visionOS
Using the Vulkan SDK
Using MoltenVK Directly
Fetching MoltenVK Source Code
Building MoltenVK
Building With Xcode
Building From the Command Line
Hiding Vulkan API Symbols
Accessing Metal Private API Calls
Install MoltenVK to Replace The Vulkan SDK libMoltenVK.dylib
Running MoltenVK Demo Applications
Using MoltenVK in Your Application
MoltenVK and Vulkan Compliance
Getting Support
Contributing to MoltenVK Development
Introduction to MoltenVK
MoltenVK is a layered implementation of Vulkan 1.4
graphics and compute functionality, that is built on Apple's Metal
graphics and compute framework on macOS, iOS, tvOS, and visionOS. MoltenVK allows
you to use Vulkan graphics and compute functionality to develop modern, cross-platform,
high-performance graphical games and applications, and to run them across many platforms,
including macOS, iOS, tvOS, visionOS, Simulators, and Mac Catalyst,
and all Apple architectures, including Apple Silicon.
Metal uses a different shading language, the Metal Shading Language (MSL), than
Vulkan, which uses SPIR-V. MoltenVK automatically converts your SPIR-V shaders
to their MSL equivalents.
To provide Vulkan capability to the macOS, iOS, tvOS, and visionOS platforms,
MoltenVK uses Apple's publicly available API's, including Metal. MoltenVK
does not use any private or undocumented API calls or features, so your app will
be compatible with all standard distribution channels, including Apple's App Store.
The MoltenVK runtime package contains two products:
MoltenVK is a implementation of an almost-complete subset of the
Vulkan 1.4 graphics and compute API.
MoltenVKShaderConverter converts SPIR-V shader code to Metal Shading Language (MSL) shader code.
The converter is embedded in the MoltenVK runtime to automatically convert SPIR-V shaders
to their MSL equivalents. In addition, the SPIR-V converter is packaged into a stand-alone command-line
MoltenVKShaderConverter macOS tool for converting shaders at development time from the command line.
Developing Vulkan Applications for macOS, iOS, tvOS, and visionOS
Using the Vulkan SDK
The recommended method for developing a Vulkan application for macOS is to use the
Vulkan SDK.
The Vulkan SDK includes a MoltenVK runtime library for macOS. Vulkan is a layered
architecture that allows applications to add additional functionality without modifying the
application itself. The Validation Layers included in the Vulkan SDK are an essential debugging
tool for application developers because they identify inappropriate use of the Vulkan API.
If you are developing a Vulkan application for macOS, it is highly recommended that you use the
Vulkan SDK and the MoltenVK library included in it.
Refer to the Vulkan SDK Getting Started
document for more info.
Because MoltenVK supports the VK_KHR_portability_subset extension, when using the
Vulkan Loader from the Vulkan SDK to run MoltenVK on macOS, the Vulkan Loader
will only include MoltenVK VkPhysicalDevices in the list returned by
vkEnumeratePhysicalDevices() if the VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR
flag is enabled in vkCreateInstance(). See the description of the VK_KHR_portability_enumeration
extension in the Vulkan specification for more information about the use of the
VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR flag.
Using MoltenVK Directly
If you are developing a Vulkan application for iOS, tvOS, or visionOS, or are
developing a Vulkan application for macOS and want to use a different version or
build of the MoltenVK runtime library than provided in the macOS Vulkan SDK,
you can access a pre-built MoltenVK binary library from the MoltenVK repository, by
selecting a repository commit from the list,
and downloading the associated MoltenVK runtime library artifact.
Finally, if you want a customized build of MoltenVK, you can follow the instructions below
to create a MoltenVK runtime library by fetching and building the MoltenVK source code.
To learn how to integrate the MoltenVK runtime library into a game or application,
see the MoltenVK_Runtime_UserGuide.md
document in the Docs directory.
Fetching MoltenVK Source Code
To fetch MoltenVK source code, clone this MoltenVK repository, and then run the
fetchDependencies script to retrieve and build several external open-source libraries
on which MoltenVK relies:
Ensure you have cmake and python3 installed:
brew install cmake
brew install python3
For faster dependency builds, you can also optionally install ninja:
brew install ninja
Clone the MoltenVK repository:
git clone https://github.com/KhronosGroup/MoltenVK.git
Retrieve and build the external libraries:
cd MoltenVK
./fetchDependencies [platform...]
When running the fetchDependencies script, you must specify one or more platforms
for which to build the external libraries. The platform choices include:
--all
--macos
--ios
--iossim
--maccat
--tvos
--tvossim
You can specify multiple of these selections. The result is a single XCFramework
for each external dependency library, with each XCFramework containing binaries for
each of the requested platforms.
The --all selection is the same as entering all of the other platform choices,
and will result in a single XCFramework for each external dependency library,
with each XCFramework containing binaries for all supported platforms and simulators
Read the full README on GitHubWhat Hacker News says
57 sourcesWe need to stomp out this immediately: yes the style and patterns of your writing matter, not just the content. That would be true even if we weren't drowning in a flood of low effort crap, which we are. Writing is not just a set of facts devoid of any context in a vacuum. If your writing style sucks that absolutely takes away from any point you might wish to make.
But the specific problem with LLMs is that they waste your time: they appear to have substance and effort put in in a way that a bullshitting human could simply never accomplish because it would take too much effort to do so, defeating the point of not just putting in effort. For example, using an LLM to triage a production issue, it chugs through logs and stacktraces and outputs a completely wrong explanation, which gets copied and pasted into an issue. It's got everything tha
Read the rest
t would indicate effort was put in: an explanation of exactly what is happening and why, with plenty of supporting information. The only problem is, it's made up and full of assertions that are false. Claude Fable just told me moments ago that a problem I was debugging was due to virtio-GPU giving back bad timestamps, confidently with an explanation of why. It wasn't and it isn't known to. Fine: I knew what I was getting. If someone copies and pastes an LLM explanation without context, I don't know what I'm getting, and LLM writing tells are the only way I can avoid shortening my lifespan spending time on things I should have been more skeptical about but my human senses failed to flag as suspicious.
When someone posts an article or github issue or PR and it's undisclosed LLM slop, then we have a problem. Again. These PRs, issues, articles look completely legit. Like this one:
https://github.com/KhronosGroup/MoltenVK/pull/2724
No bad intentions involved: the person just simply couldn't tell when the LLM was bullshitting it, and his PR passed the sniff test just enough to get merged and cause regressions.
So if something outright smells like LLM slop from the writing style, that's a bad sign. The author has probably not written most of the sentences as they are presented, which is hard to distinguish from them not having written them at all. If they had proofread the article, they would have hopefully also noticed the repetitive, annoying LLM writing style and fixed it. When they don't, it tells me one of two things:
1. They didn't really put that much effort in, OR
2. They seriously lack taste.
Neither option is really super good.
It's not good that we're allowing people to think this isn't an issue. It definitely is an issue. It will become a worse issue once someone figures out how to fix the LLM slop writing style in post training, because then we will no longer have any good signal that human effort was put in to any prose at all.
I'll leave my opinion about this specific article out of it because it's really not specifically about this article. I can only think of one reason for people to make these bad faith arguments in favor of ignoring the glowing red "I DID NOT PUT ANY EFFORT INTO THIS" signs LLMs currently leave all over your work, and that is hoping that the pathway stays open for yourself to use.
Off the top of my head, here is what that needs:
1. Implementing PR_SET_SYSCALL_USER_DISPATCH
2. Implementing ntsync
3. Implementing OpenGL 4.6 support (currently only OpenGL 4.1 is supported)
4. Implementing Vulkan 1.4 with various extensions used by DXVK and vkd3d-proton.
That said, there are alternatives to those things.
1. Not implementing this would just break games like Jurassic World where DRM hard codes Windows syscalls. I do not believe that there are many of these, although I could be wrong.
2. There is https://github.com/marzent/wine-msync, although implementing ntsync in the XNU kernel would be better.
3. The latest OpenGL isn't that important these days now that Vulkan has been widely adopted, although having the latest version would be nice to have for parity. Not many things would suffer if it were omitted.
Read the rest
4. They could add the things needed for MoltenVK to support Vulkan 1.4 with those extensions on top of Metal:
https://github.com/KhronosGroup/MoltenVK/issues/203
It is a shame that they do not work with Valve on these things. If they did, Proton likely would be supported for MacOS from within Steam and the GPTK would benefit.
MoltenVK now supports Vulkan 1.3 features for Metal
3 points · Open discussionPeople have already mentioned Metal, but if you want cross platform, https://github.com/gfx-rs/wgpu has a vulkan-like API and cross compiles to all the various GPU frameworks. I believe it uses https://github.com/KhronosGroup/MoltenVK to run on Macs. You can also see the metal shader transpilation results for debugging.
In Ask HN: Resources for general purpose GPU development on Apple's M* chips?Since bringing modern OpenGL and Vulkan onto Apple Silicon is impossible without an emulation layer anyway, could, theoretically, a native Metal API for Linux be created? Or is Metal too ingrained in macOS SDKs? MoltenVK is attempting to solve the same issues Alyssa was talking about in her talk [1, the last comment on the issue is hers]
[1] https://github.com/KhronosGroup/MoltenVK/issues/1524
In An Update on Apple M1/M2 GPU DriversMoltenVK doesn't support geometry shaders for ~3 years now[0]
[0] https://github.com/KhronosGroup/MoltenVK/issues/1524
In AAA Gaming on Asahi LinuxCause MoltenVK [1] is used, I think.
---
[1]: https://github.com/KhronosGroup/MoltenVK
In AAA Gaming on Asahi LinuxYeah, no native Vulkan on macOS. MoltenVK[0] is a workaround. Decent for some projects.
[0] https://github.com/KhronosGroup/MoltenVK
In Valve is testing ARM64 support for popular gamesGames written with Vulkan can run on MacOS with the help of the MoltenVK [1]. You don't need to rewrite the game, just recompile for MacOS. The game can use Vulkan API but loads the MoltenVK shared library at runtime. It acts as a translation layer for Metal which is very similar to Vulkan. There are some gotchas, such as you can not use geometry shaders because Metal does not support them.
[1]: https://github.com/KhronosGroup/MoltenVK
In Epic Games Store and Fortnite Arrive on EU iPhoneshttps://github.com/KhronosGroup/MoltenVK proves that it is possible, but it is limited by having to go through Metal.
In Vulkan1.3 on the M1 in one monthMoltenVK is a layered implementation of Vulkan 1.2
2 points · Open discussionhttps://github.com/KhronosGroup/MoltenVK
Translating between rendering APIs is not really the problem. The GPU design is more different than the API is.
In Valve says Counter-Strike 2 for macOS not happening, there aren't enough playersMoltenVK is explicitly not enough for vkd3d-proton. It lacks features that are now mandatory for acceptable performance. So lack of native Vulkan there is surely a deal breaker.
I think VK_EXT_descriptor_buffer is a critical one, and there are probably more: https://www.khronos.org/blog/vk-ext-descriptor-buffer
And that's Vulkan 1.3 which MoltenVK doesn't support (yet):
https://github.com/KhronosGroup/MoltenVK/issues/1776
In 5 years ago Valve released ProtonKhronos maintains MoltenVk though, which is as "official" as it gets: https://github.com/KhronosGroup/MoltenVK
...technically, Vulkan on Windows is also only supported via 3rd-parties (the GPU vendors), so the situation isn't actually all that different. The "Vulkan driver" is just bundled with the application on Mac instead of installed separately.
In Meta releases Intermediate Graphics LibraryShowing the 15 most recent of 57 sources. Enable JavaScript to search and browse every indexed mention.