Apple's container hits 1.0 — and quietly becomes a real Linux dev environment

What happened

Apple tagged version 1.0.0 of `container`, the Swift-written, Apple-silicon-optimized runtime for Linux containers on macOS. The headline change isn't the version number — it's the promotion of container machines out of the experimental corner of the docs and into a first-class feature, with persistence and host filesystem mounting now supported.

That last detail matters more than the 1.0 sticker. Until container machines landed, `container` was a faster way to run ephemeral OCI workloads on a Mac; with persistence and mounts, it becomes a place you can actually do work. You can keep state across reboots, bind-mount your source tree into a Linux VM, and treat the result as a long-lived Linux box you SSH into — the same workflow developers have been hacking together with multipass, Lima, or a Vagrant box for the better part of a decade.

Tim Sneath, who runs developer tools comms at Apple, made the framing explicit on Hacker News: "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 1166-point HN thread suggests the audience heard it.

Why it matters

The architectural choice that drew attention at the 0.x preview hasn't changed: every container runs inside its own lightweight VM, not as a process group sharing a host kernel. That's the opposite of how Docker Desktop and OrbStack work, both of which boot a single Linux VM and run containers as namespaces inside it. The trade-off is well known — VM-per-container costs you memory and startup latency in exchange for stronger isolation and a kernel you can customize per workload.

What changed at 1.0 is that the dev-environment use case now has a sanctioned path. The interesting comparison isn't `container` vs Docker Desktop anymore — it's `container` vs OrbStack as a Linux-on-Mac development surface. OrbStack has won that market on polish: instant boots, transparent file sharing, integrated DNS, and a UI that doesn't fight you. It's also $8/month per seat for commercial use. Apple's offering is free, signed by Apple, and shipped from the same org that controls the hypervisor framework it's built on.

The community reaction on the HN thread leans pragmatic. "OrbStack works really well for me. I wonder how it's compared to this performance wise," asked one commenter — a question nobody in the thread could answer with hard numbers. That's the gap. There's no public benchmark suite yet comparing cold-start, sustained I/O on bind mounts, or memory overhead between `container` 1.0 and OrbStack on the same M-series hardware. Until someone runs that comparison, claims in either direction are vibes.

There's also a question several commenters raised about why macOS doesn't take a WSL1-style approach — translating Linux syscalls directly rather than running a full kernel. "It seems like macOS being another *nix would make a lot of what was hard for windows, easy for mac," one developer wrote. The short answer is that Darwin and Linux are *nix in the same way Java and JavaScript are languages: the surface overlap is misleading. Linux's procfs, sysfs, eventfd, io_uring, cgroups v2 semantics, namespace primitives, and a thousand syscall edge cases don't translate cleanly. Microsoft tried syscall translation with WSL1 and gave up — WSL2 is also a VM, because at scale the translation surface is bigger than the VM overhead. Apple is, in effect, conceding that lesson upfront.

The Swift-native angle deserves a note too. `container` is written in Swift, links against Virtualization.framework directly, and runs on Apple silicon with no x86 emulation path. For Apple, that's a forcing function — it gives Swift on Linux a first-party use case beyond server-side experiments, and it ties the tool's performance story directly to hardware Apple controls end-to-end.

What this means for your stack

If you're on OrbStack and happy, there's no fire to put out. The migration cost is real (different CLI, different volume semantics, no GUI yet), and OrbStack's polish advantage will persist for at least another release cycle. Wait for someone credible to publish bind-mount throughput and cold-start numbers before you migrate a working setup.

If you've been hacking Lima, multipass, or a hand-rolled UTM VM as your Linux dev box, container 1.0 is worth a serious look this week. The persistence + mount story removes the main reason most of those workflows existed. The fact that it ships from Apple means it'll get tested against every new macOS release before that release ships, which is more than you can say for community-maintained alternatives.

If you're building developer tooling that targets Macs — internal platform teams, this means you — start tracking `container` as the eventual default. The same way Rosetta 2 quietly became the assumed runtime for x86 binaries on Apple silicon, a Swift-native VM runtime shipped by Apple is going to become the assumed substrate for Linux work on Macs. Tooling that hard-codes Docker Desktop or assumes a shared-kernel runtime is going to look dated within 18 months.

Looking ahead

The next inflection point isn't another container release — it's the WWDC session where Apple shows what container machines look like inside Xcode, or as a Swift Package Manager target. That's when this stops being a side project for the dev tools team and becomes infrastructure the whole Mac developer experience leans on. Until then, run it on a side project, file the issues, and bookmark whoever ends up publishing the OrbStack comparison benchmarks. Someone will.