Apple's `container` hits 1.0: the quiet WSL2 for macOS

What happened

On June 10, Apple cut the v1.0.0 tag on [`apple/container`](https://github.com/apple/container), the Swift-native container runtime announced at WWDC 2025 and refined through a year of betas. The release itself is terse — a GitHub tag, a one-line devblog post — but the timing matters: 1.0 lands a few days before WWDC 2026, and the repo quietly grew a new piece of documentation called `container-machine.md` that reframes what the tool actually is.

The headline isn't that Apple ships OCI containers on macOS — it's that Apple now ships a sanctioned, persistent Linux development environment on macOS. `container machine` creates long-lived lightweight VMs with filesystem mounts and state that survives reboots. Tim Sneath, who runs developer tools at Apple, clarified the framing directly in the HN thread: "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."

The architectural choice that drew the loudest reaction on Hacker News (1,211 points, top of the front page) is unchanged from the beta: each container runs in its own VM. Not a shared kernel à la Docker Desktop or OrbStack — a full hypervisor instance per workload, talking to Apple's Virtualization framework directly from Swift. One commenter asked the obvious question — "Do these containers share a common kernel?" — and answered themselves after digging into the technical docs: VM per container.

Why it matters

The per-container-VM model is the part most worth chewing on, because it cuts against twenty years of container orthodoxy. Docker's whole pitch was that namespaces + cgroups gave you process-level isolation at near-zero overhead; you didn't need a hypervisor. Apple is betting that on Apple silicon, with Virtualization.framework's hardware acceleration, the overhead of a microVM per container is small enough that the security and kernel-independence wins are worth it. It's effectively the Kata Containers / Firecracker thesis, shipped as the default on every M-series Mac.

The community comparison everyone wanted was against OrbStack, which has dominated the "Docker Desktop but not terrible" niche on macOS for the last two years. Early benchmarks in the comments are anecdotal — "OrbStack works really well for me, I wonder how it's compared to this performance wise" was a common refrain — but the structural difference is clear: OrbStack runs a single shared Linux VM with all containers as siblings inside it, so cold-start is microseconds and memory is pooled. Apple's `container` pays a VM-boot tax per workload but gets you kernel-level isolation that OrbStack architecturally cannot provide. For most dev loops that's a worse tradeoff. For multi-tenant CI runners, untrusted workloads, or anyone shipping containers to Kata-backed production, it's a better one.

The more interesting framing came from another commenter asking why macOS doesn't try a WSL1-style approach — syscall translation rather than virtualization, given that macOS is itself a Unix. It's a fair question and the answer is instructive: WSL1 worked for the 80% of Linux software that touched a narrow syscall surface, then collapsed on the long tail of `inotify`, `/proc` semantics, networking edge cases, and anything that touched a kernel module. Microsoft gave up and shipped WSL2, which is a Hyper-V VM. Apple skipped the WSL1 detour entirely and went straight to the WSL2 architecture — a hardware-accelerated Linux VM that talks to the host through a well-defined interface. The lesson Microsoft learned the expensive way, Apple just copied.

And that's really what `container-machine` is: a sanctioned, first-party, free, Swift-native WSL2 for the Mac. The pjmlp comment in the thread — "With the BUILD and WWDC 2026 announcements, it is the Year of Linux Containers Desktop" — was meant as a joke, but it points at something real. Both major desktop OS vendors have now concluded that the right way to run Linux on their platforms is hardware virtualization with a clean interface, not emulation, not compatibility shims, and not their own kernel. The Linux ABI won.

What this means for your stack

If you're on Apple silicon and currently paying for OrbStack ($8/user/month for teams) or wrestling with Docker Desktop's licensing terms, you now have a free first-party option that handles the 80% case. Apple's `container` is not going to beat OrbStack on raw container-per-second throughput in 2026, but it ships in the OS box, gets reviewed by Apple's security team, and won't get acquired and enshittified. For solo devs and small teams running a handful of containers for local services — Postgres, Redis, a build environment — that calculus is going to push a lot of seats off OrbStack and Docker Desktop over the next year.

The `container-machine` story changes the audience again. If you've been using Lima, multipass, UTM, or a hand-rolled VZVirtualMachine wrapper to keep a persistent Ubuntu around for non-container work — building Rust against `musl`, running `nix-shell`, debugging kernel-adjacent code — `container-machine` collapses that into a first-party tool. The persistence model and filesystem mount support are explicitly aimed at the "I just want a Linux box on my Mac" use case, not the "I want to run my microservice locally" one. That's a quieter but stickier market than container orchestration.

The CI implication is the one nobody is talking about yet. GitHub Actions macOS runners, Buildkite Mac fleets, and any self-hosted Apple silicon CI is now a candidate for switching to per-job VMs without the licensing headache of Anka or the operational complexity of Tart. If `container` exposes a stable enough API by mid-2026, expect at least one major CI vendor to ship native support and price macOS minutes accordingly.

Looking ahead

The interesting fight in 2026 isn't "will Apple's `container` kill OrbStack" — OrbStack will keep the performance crown and the polish, the way Iterm2 kept its crown after Apple shipped a real Terminal. The interesting fight is whether containerd, Kubernetes-in-a-box, and the broader cloud-native ecosystem normalize on Apple's per-VM model as the macOS default, or stay on the shared-kernel OrbStack model because the dev loop is faster. Bet on bifurcation: production-shaped workloads (multi-tenant, security-sensitive) gravitate to `container`; dev-shaped workloads (a Postgres, a Redis, hot reload) stay on OrbStack. Either way, Docker Desktop on macOS just became the third choice on its own platform, and Apple barely raised its voice to do it.