Apple's Container Machines are the WSL parity macOS quietly needed

What happened

Apple's `container` project — the Swift-native, Apple-silicon-optimized container runtime that shipped earlier this year — quietly added a feature called Container Machines, documented at `apple/container/blob/main/docs/container-machine.md`. The HN thread hit 998 points within hours, and the framing in the comments shifted fast once Apple's own director of developer relations, Tim Sneath, dropped in to clarify the scope.

Sneath's clarification is the actual story: "This is not only OCI containers — container machines add support for persistence and filesystem mounting, making container machines a great lightweight Linux environment for developers using macOS." That sentence reframes the entire project. Up to now, `container` looked like Apple's answer to Docker Desktop: a way to run OCI images on Apple silicon without the licensing baggage. With Container Machines, it's also a way to run a persistent Linux box you can mount your code into, install packages on, and treat as a real dev environment.

The architectural details that dominated the first wave of coverage — each container runs in its own lightweight VM via Apple's Virtualization framework, no shared kernel like Docker's Linux VM model — are now the supporting cast. The headline change is that a Container Machine survives reboots, holds state, and exposes a filesystem you can write to from macOS. That's not a container runtime feature. That's a Linux-on-macOS feature.

Why it matters

For a decade, the macOS Linux story has been outsourced. Docker Desktop runs a hidden LinuxKit VM. OrbStack — which one commenter on the thread defended energetically ("OrbStack works really well for me, I wonder how it's compared to this performance wise") — runs its own optimized VM with clever filesystem sharing. Lima, colima, multipass, UTM, and a long tail of wrappers all exist because Apple never offered a sanctioned way to run Linux workloads on macOS the way Microsoft eventually did with WSL.

The WSL comparison is the right frame, and one HN commenter (cogman10) asked the obvious question: "Is there any reason why macOS doesn't try a WSL1 style approach? I get why that didn't fully work out for windows, but it seems like macOS being another *nix would make a lot of what was hard for windows, easy for mac." The answer Apple appears to have given — quietly, without a keynote — is: we're doing WSL2, not WSL1. Each Linux environment gets a real kernel in a real VM, because that's what proved durable on Windows after Microsoft tried and abandoned the syscall-translation approach. Apple skipped the lesson and went straight to the hypervisor.

The performance question is where this gets interesting. Apple's Virtualization framework is the same primitive that already powers Docker Desktop's optional VZ backend, OrbStack, and macOS's own "Run Linux" demos at WWDC. The difference is integration. When the runtime, the VM scheduler, the filesystem bridge, and the Swift bindings all ship from the same team, the death-by-a-thousand-cuts that plagues Docker Desktop on Apple silicon — bind mount latency, file event propagation, ARM-vs-x86 emulation footguns — can actually get fixed at the layer that's causing them, not papered over in a wrapper. That's the OrbStack moat, and Apple just walked into it with first-party authority.

pjmlp on the thread called this "the Year of Linux Containers Desktop" — half joke, half reality. Between Apple's `container`, Microsoft's continued WSL investment, and the slow death of Docker Desktop's reason to exist as a paid product, the desktop Linux story is finally converging on "your OS vendor handles it." Which is, of course, exactly where Microsoft has been for five years.

What this means for your stack

If you're on Apple silicon and already paying for Docker Desktop, the calculus is now: how soon can `apple/container` cover your workflow? For pure OCI workloads — `docker run`, compose files, CI parity — it's plausibly there already. For dev-environment workloads — long-lived Linux box, apt-get installs, code mounted from `~/dev`, port forwarding to a browser on macOS — Container Machines just unlocked the missing piece. If you've been keeping a colima or OrbStack instance alive specifically to have a persistent Linux shell with your repo mounted in, you can probably retire it within a quarter.

For OrbStack specifically, this is the existential question. OrbStack's pitch has been: faster than Docker Desktop, better filesystem sharing, persistent Linux machines on the side. Apple just matched the third point with a free, OS-vendor-shipped tool that's going to get tighter kernel integration with every macOS release. OrbStack's response will probably be to lean harder into developer-experience polish — GUI, networking, k8s integration — because the raw-capability gap is closing. The HN commenter asking how OrbStack compares performance-wise will get an answer in the next few weeks, and Apple's home-field advantage on kernel-level optimization is not subtle.

For CI and reproducibility, the bigger play is that `container` is open source and Swift-native. A container runtime that ships in Apple's developer toolchain, runs on every M-series Mac in the company by default, and produces OCI-compatible images is a strong nudge toward "build on Mac, deploy to Linux" as a first-class workflow — exactly the WSL flywheel that locked a generation of cross-platform developers onto Windows. If you're a tooling vendor — dev container providers, language runtimes, CLI shippers — the Apple-silicon-Linux-container target just became table stakes.

Looking ahead

The pattern to watch is whether Apple keeps `container` as a developer-tools side project or pulls it into Xcode and the macOS shell the way Microsoft pulled WSL into Windows Terminal and VS Code. The persistence and filesystem-mounting features in Container Machines are the precondition for that move — you can't ship "run Linux from Spotlight" without state. Sneath's framing ("a great lightweight Linux environment for developers using macOS") reads like a stalking horse for a much larger story Apple isn't ready to tell yet. The Year of Linux Containers Desktop is real; the question is whether Apple is willing to compete for it, or whether `container` stays at the polite edge of the Mac developer experience while OrbStack and Docker Desktop do the dirty work of making it usable.