An experimental Mac project runs ARM64 SteamOS and translates games through several layers
Steamac targets Apple Silicon and macOS 15+, with roughly 150GB of free space. Its README documents game-specific limits and VM-blocking anti-cheat incompatibility.
SteamOS on a Mac takes a surprisingly long route to the screen.
Steamac uses libkrun for the VM, then routes Vulkan graphics through Mesa Venus and a host renderer to MoltenVK and Apple’s Metal. For x86 Windows game paths, FEX and Proton add their own translation work. The README’s architecture diagram draws the layers explicitly, which is useful when a game’s failure could sit in more than one place.
The project calls for an Apple Silicon Mac, macOS 15 or later and roughly 150GB free for a sparse disk image. Building also needs a full Xcode installation and a Linux-container toolchain. A sparse image is rather like an expandable suitcase: its current size does not tell you how much room it may need later.
The build instructions separate the Mac side from the Linux guest. The host supplies the VM launcher and graphics components, while Linux containers build the kernel, Mesa and disk image. The Valve image is downloaded with signature and hash checks. This is enough moving software to make the named build requirements more useful than a general claim that the machine runs Linux.
There are also two documented graphics-backend choices. MoltenVK is the default route; KosmicKrisp is an experimental alternative requiring macOS 26 or later. Those requirements differ from the base macOS 15 requirement. Someone with a compatible Mac can still lack the operating-system version needed for a particular graphics path.
The shader behavior explains one kind of delay that could look like inconsistent performance. The project reports Metal compilation when a new pipeline appears, followed by much shorter processing after the result is cached. That makes a first visit to a scene different from a later visit. Comparing two runs without recording whether the cache is warm would mix the setup cost into the apparent game speed.
The README documents Steam shader pre-caching and background processing as enabled defaults, with settings to change them. It also describes the space consumed by per-game transcoded video downloads. The sparse system disk is therefore only part of the storage plan: installed games and their supporting files need room too. The initial free-space requirement won’t tell a player how large the final library becomes.
The status section is most useful when read game by game and component by component. A successful desktop, a rendered test and an actual game session are different pieces of evidence. The project supplies those distinctions rather than turning the existence of a Steam window into a blanket compatibility promise.
The project says SteamOS is downloaded from Valve after license acceptance and is not distributed with the project itself. Steamac is also unaffiliated with Valve; using Valve’s image does not make this an official Mac product.
A useful next result would pair a named game, machine and graphics backend with repeatable behavior after the shader cache warms. That would help separate a successful demonstration from a setup someone wants to keep using.