Apple container 1.0: why containers on a Mac will always be a workaround (and how Apple is hiding the seams)

What happened

On 9 June 2026 — exactly one year after announcing it at WWDC 2025 — Apple shipped version 1.0 of container, its open source tool for running Linux containers on macOS. It comes with the Containerization framework, written in Swift, and it speaks standard OCI images: you can pull from Docker Hub or any registry you already use.

The headline doing the rounds is the usual one: "Apple kills Docker". It doesn't. What Apple has built is genuinely interesting, but to see what it actually delivers — and what's marketing — you first need to internalise something that plenty of daily Docker users never quite have: a container is not Docker technology, it's a Linux kernel feature.

Containers are only native on Linux

On Linux, a container is an ordinary process on your machine that the kernel fits with blinkers: namespaces so it can't see other processes or the host's network, cgroups to cap its CPU and memory, and a layered filesystem. No virtualisation, no middle layer, no translation. Run ps aux on the host and your containers' processes show up like any others.

That's why Docker on Linux just works, and why it's what runs on practically every server on the planet. The "container" is the kernel doing its job; Docker is merely the convenient tool that asks for it.

The trouble starts when you want the same thing on a Mac. The macOS kernel (XNU) has no namespaces and no cgroups, and on top of that, container images ship binaries compiled for Linux: the MySQL inside the image is a Linux executable, not a macOS one. The inescapable conclusion: to run a Linux container on a Mac you need a real Linux kernel running somewhere. In other words, a virtual machine. Always. There is no way around it.

Everything sold as "Docker on Mac" is really a Linux VM in disguise, and the odd behaviours anyone notices in their first week leak out of the seams of that disguise:

• Slow disk: bind mounts (-v ./code:/app) cross the macOS↔VM border through a shared-file protocol. That's why composer install or npm install over a mounted volume is painfully slow on a Mac and perfectly normal on Linux.
• Weird networking: host.docker.internal, a --network host that doesn't really work... because the container's network lives inside the VM, not on your Mac.
• Hijacked RAM: Docker Desktop's VM reserves however many gigabytes you configured and stays up as long as the app runs, whether you have 0 or 20 containers going.

What Apple is doing differently

Here's the interesting technical part. Docker Desktop solves the problem with one big shared Linux VM running dockerd inside, and all your containers are processes of that single VM sharing its kernel. It is, quite literally, "a VirtualBox with Docker inside".

Apple went the opposite way: one micro-VM per container. Each container boots its own lightweight virtual machine with a minimal Linux kernel and a tiny init (vminitd, written in Swift) that executes the container's process directly — no daemon anywhere. When the container dies, its VM vanishes with it.

Apple didn't invent this. It's the same pattern as AWS Firecracker (what runs every Lambda function) and Kata Containers: micro-VMs so cheap to spin up that you can afford one per workload. The novelty is shipping it out of the box on a development laptop.

A framing we like: on Linux, a container is a process disguised as a machine. On Apple's Mac, it's a machine disguised as a process. The user experience looks similar; the plumbing is exactly inverted.

Putting the claims to the test

"It uses less RAM than Docker Desktop" — half true

At idle, yes: zero containers = zero VMs = zero RAM, whereas Docker Desktop's VM claims its gigabytes just for existing. But each Apple micro-VM boots its own kernel and gets 1 GB allocated by default, so with many simultaneous containers the maths flips: N kernels weigh more than one shared kernel. The saving is real if you spin up the occasional standalone container; for an eight-service compose stack, not so much.

"Hardware-level isolation" — marketing phrasing, real substance

In Docker, two containers share a kernel: one kernel exploit from inside a container compromises all the others, and namespace escapes are a vulnerability class that shows up every single year. With one VM per container, escaping means breaking the hypervisor — the CPU's virtualisation extensions, hence "hardware" — which is a far harder wall. It's the exact sales pitch behind Firecracker at AWS. That said: it's a multi-tenancy argument, not a local-development one. For your throwaway MariaDB it makes no difference whatsoever.

"Sub-second startup" — true, and the most polished part

Minimal kernel, minimal rootfs, no daemon. Starting a container is practically indistinguishable from launching it on native Linux. Apple did its homework here.

The toll that remains

Bind mounts still cross the macOS↔Linux border (virtiofs), so shared file access will keep being slower than native Linux. They've padded the workaround; they haven't removed it. Physics doesn't change: on a Mac there will always be a VM in the middle; on Linux, never.

The irony of the move

There's something amusing about the fact that, after years of complaints about Docker Desktop being "heavy", Apple's alternative boots an entire VM with its own kernel for every container. On paper that sounds heavier still; Apple's bet is that on its silicon, micro-VMs are so cheap you won't notice.

But look at what people actually criticised about Docker. Nobody questioned the container concept — that one won outright: OCI images are the standard and Apple adopts them as-is, no proprietary format. The complaints targeted Docker Desktop the product: the always-on VM, the disk performance, the root daemon and, above all, the 2021 licence change, when Docker Inc. started charging businesses a subscription. That's where Colima, OrbStack and Podman Desktop came from — and now Apple, running its classic play: the standard already exists, the dominant implementation has friction and a licence toll, so let's bake it into the operating system for free.

What's at stake isn't Docker the concept. It's Docker Desktop the product.

Limitations before you get excited

• Apple Silicon only (M1 onwards). No Intel.
• Version 1.0 requires macOS 26 (Tahoe); support on older releases is limited or non-existent.
• No full Docker Compose equivalent. For a project with several linked services, Docker Desktop or OrbStack remain more comfortable today.
• The tooling ecosystem (CI, IDE integrations, team scripts) still revolves around Docker.

What changes for you (probably nothing on the server)

If you run servers: nothing. Containers on Linux are native, there's nothing to fix there, and deployments will keep being Docker or Podman on Linux as always. Apple's container doesn't compete on that turf and doesn't try to.

If you develop on an Apple Silicon Mac: it's a serious alternative to keeping Docker Desktop installed for standalone containers — a test database, an isolated PHP, a throwaway environment — with no permanent VM eating resources and no licence in the way. It installs from a .pkg on the GitHub releases page and starts with container system start.

And if your project is a many-service compose stack: for now, stay where you are. The 1.0 marks a stable API contract, not feature parity.

References

• apple/container — GitHub
• apple/containerization — GitHub
• Containerization — Apple Open Source
• Apple Containers on macOS: A Technical Comparison With Docker — The New Stack
• Under the hood with Apple's new Containerization framework — Anil Madhavapeddy