Apple's container tool gives each container its own VM. That's the point.

What happened

Apple's `container` project — open-sourced at github.com/apple/container and written in Swift, optimized for Apple silicon — now ships container machines: a thin VM layer that gives each container its own kernel, persistent state, and filesystem mounts on the host. The docs (`docs/container-machine.md`) describe it as "a tool for creating and running Linux containers using lightweight virtual machines on a Mac." The Hacker News thread hit 573 points within hours, with Apple's own Tim Sneath jumping in to clarify the scope.

"This is not only OCI containers," Sneath wrote. "Container machines add support for persistence and filesystem mounting, making container machines a great lightweight Linux environment for developers using macOS." That single sentence reframes the whole project. The original `container` tool, announced at WWDC 2025, was an OCI runtime — fine for `docker run alpine`, useless for the actual way developers use Linux on a Mac (long-lived dev envs with mounted source trees and persistent package caches). Container machines close that gap.

The architectural choice that drew the most discussion: it's one VM per container, not a shared kernel. A commenter walking the technical docs confirmed it (`github.com/apple/container/blob/main/docs/technical-...`). Apple is leaning into Virtualization.framework hard and explicitly rejecting the Docker-on-Mac approach of one fat Linux VM running a shared dockerd.

Why it matters

The obvious comparison is OrbStack, which several commenters flagged immediately ("OrbStack works really well for me. I wonder how it's compared to this performance wise"). OrbStack runs a single tuned Linux VM and multiplexes containers inside it — the classic model, with the classic tradeoffs: fast boot, shared kernel attack surface, noisy-neighbor I/O contention, and a single point of failure for the dev loop. Apple's per-container VM model trades cold-start latency for isolation, reproducibility, and — critically — the ability to run different kernel versions side by side without rebooting anything.

The second comparison that keeps coming up is WSL. "Is there any reason why macOS doesn't try a WSL1 style approach?" asked one commenter. "macOS being another *nix would make a lot of what was hard for windows, easy for Mac." It's the right question with the wrong premise. WSL1 translated Linux syscalls to NT — a project Microsoft eventually abandoned for WSL2's VM-based approach precisely because syscall compatibility is a tar pit. Apple, by shipping container machines, is admitting publicly what's been obvious internally for a decade: there will never be a macOS Subsystem for Linux. The answer is virtualization, and the bet is that Apple silicon's hardware virtualization is fast enough to make per-container VMs viable.

The "Year of Linux Containers Desktop" line from another commenter (`pjmlp`) is glib but not wrong. Between Apple's `container`, Microsoft's continued WSL2 investment, and the BUILD/WWDC 2026 announcements, both desktop platforms have now converged on the same answer: Linux runs in a hypervisor next to the host OS, not inside it. The status quo on form factors won't change, but the *substrate* underneath every dev Mac and dev PC is now a VM orchestrator.

What's genuinely new here, and underdiscussed in the thread, is what Swift-native means for the cold path. Docker Desktop on macOS is an Electron app wrapping a Go daemon wrapping a Linux VM. Each layer eats RAM. `container` is a native Swift binary calling Virtualization.framework directly. If Apple's implementation gets within 20% of OrbStack on benchmarks while using a fraction of the resident memory, the OSS-vs-paid calculus on Mac container tooling flips overnight.

What this means for your stack

If you ship on Apple silicon and your dev loop involves containers — which, for most backend and ML teams, it does — you have three concrete decisions to revisit in the next quarter.

Docker Desktop licensing. The $9/user/month Docker Desktop subscription has been an annoying line item since 2022. Apple's tool doesn't replace `docker build` ecosystem tooling for everyone, but for a meaningful slice of "I just need to run a postgres and a redis locally" use cases, it does. Run the numbers on a 50-engineer team and the savings buy a non-trivial AWS budget.

OrbStack vs container. OrbStack is excellent and worth its $8/user/month for teams that need its Kubernetes integration and polished UI. But "OrbStack works really well" is exactly the kind of sentiment Apple is trying to commoditize, and the per-container-VM architecture gives Apple a structural isolation story OrbStack can't match without a rewrite. Watch the benchmarks over the next 90 days.

CI parity. Per-container VMs on the dev side and per-container VMs on production runners (Fly Machines, AWS Fargate, modal.com) means your local environment finally matches your production environment's isolation model. The "works on my machine" bugs that came from sharing a kernel between containers locally but not in prod just got harder to write.

Looking ahead

The interesting question isn't whether `container` displaces Docker Desktop — it will, partially, for the unsexy 60% of use cases that don't need the full ecosystem. The question is whether Apple intends to ship the rest of the stack: a Compose-equivalent, a Kubernetes integration, a remote dev story that competes with Codespaces and Devcontainers. The container-machine docs landing this quietly, with a senior Apple developer-relations exec showing up in the HN thread to evangelize, suggests this is a multi-year platform play, not a checkbox. Senior devs on macOS should treat the next two WWDCs as where this either compounds into a real platform or stalls into another `osascript` — a tool you keep meaning to use and never quite do.