Apple's container vs Docker Desktop on the Mac

For most of the last decade, “run a container on a Mac” meant Docker Desktop. It worked. It still works. But somewhere along the way it became the loudest app on my machine: update badges in the menu bar, restart-the-daemon prompts, the occasional “your licence terms are changing” email. macOS stays out of the way; Docker Desktop has a habit of not.

Apple quietly shipped a contender. apple/container reached version 1.0 on 9 June 2026, roughly a year after it was first shown at WWDC 2025. After a few weeks of using it daily, here’s where I’ve landed.

What apple/container actually is

apple/container is Apple’s open source container runtime for macOS, written in Swift and tuned for Apple silicon. Each Linux container runs inside its own lightweight virtual machine, built on the macOS Virtualization framework. There’s no big daemon idling in the background and no menu-bar whale.

A few things that matter:

• OCI all the way through. It pulls, runs, builds and pushes standard OCI images, so anything in Docker Hub, ghcr.io or your private registry just works. Images you build here run anywhere OCI runs.
• A VM per container. Every container gets its own micro-VM rather than sharing one Linux host, which means stronger isolation by default.
• The Containerization Swift package does the heavy lifting underneath for image, filesystem and process management.
• Apache-2.0, and you can read every line of it on GitHub.

It targets macOS 26 (Tahoe), runs on macOS 15 (Sequoia), and is Apple-silicon only. If you’re on an Intel Mac, this isn’t the tool for you.

Where it quietly beats Docker Desktop

The noise is gone. No menu-bar icon, no nagging daemon. You install it with Homebrew, start the background service, and forget it exists until you need it.

The resource footprint is lighter. Because the Virtualization framework allocates memory lazily and balloons it back to the host when a VM is idle, an idle builder shows a few hundred megabytes in Activity Monitor rather than the chunky reservation Docker Desktop tends to sit on.

Native arm64, with Rosetta for the rest. amd64 layers run through Rosetta during builds, which is dramatically faster than the QEMU translation path you fall back to elsewhere on the Mac.

No Docker subscription to think about. Docker Desktop is free for small outfits (under 250 employees and under US$10M revenue) but paid above either of those lines. If your team has crossed one, apple/container is genuinely free and removes a procurement conversation.

Where Docker Desktop still wins

This is the part the release notes won’t shout about. apple/container is genuinely good now, but its surface area is smaller.

• Docker Compose isn’t first-class. You can run multi-service stacks, but there’s no native docker compose up experience. If your whole project hangs off a compose.yaml, this is the biggest speed bump.
• A handful of flags are missing or behave differently. Things like --network host, --restart=always, --privileged and the health-check flags are the ones people trip on. You reach for --cap-add instead of --privileged, which is arguably cleaner, but it’s still a rewrite of muscle memory. Worth skimming the v1.0 release notes for the current list.
• Devcontainers lean on Docker. VS Code and Cursor’s devcontainer flow expects a Docker socket. That story is improving, but it isn’t seamless yet.
• Cold start in tight loops. Each container is a real VM, which boots fast (under a second on the v1.0 numbers), but a fresh run still has more moving parts than Docker Desktop’s warm daemon. For a tight test, edit, rebuild loop you’ll feel the extra beat.
• Small-file I/O. Bind-mounting a directory full of tens of thousands of files (think node_modules) is slower than on Docker Desktop. Great for sequential reads, rough for that specific case.

These are moving targets. v1.0 added a persistent “Container Machine” mode and new networking, and the gap closes a little with each release.

How painful is the switch, really

Honestly, less than I expected.

brew install container
brew services start container

That’s most of it. The CLI is close enough to docker that your fingers mostly do the right thing: container run, container build, container images, container push. The two that catch people are container ls instead of docker ps, and the absence of docker compose.

The one thing worth doing on a fresh machine is bumping the defaults. Out of the box, containers get a fairly lean slice of CPU and memory and the builder VM is even smaller, so the first real container build can feel sluggish until you give it room. Properties like container.cpus, container.memory and the builder equivalents (build.cpus, build.memory) are one-liners, and because memory is a ceiling rather than a hard reservation, you can afford to be generous with them.

If your day is “build an image, run a thing, hit it from a browser”, you’ll be productive in an afternoon. If your day is docker compose up on a twelve-service stack, keep Docker around for now.

It’s not just Apple vs Docker

Worth naming the others, because this isn’t a two-horse race:

• OrbStack is the polished, fast commercial option with a free tier. It’s the closest thing to “Docker Desktop but nicer” if you want a GUI and don’t mind the licence.
• Colima is the quiet favourite: a tiny, free VM-on-Mac that hands you a real Docker socket, so docker compose and everything else just works.
• Podman and Rancher Desktop are the daemonless and Kubernetes-flavoured open source options respectively.
• Lima is the low-level VM layer underneath several of these.

apple/container’s angle is that it’s first-party, native to macOS, and betting hard on the VM-per-container model. Whether that matters to you depends on whether you value isolation and native integration more than ecosystem completeness.

The honest verdict

For running a dev database, building images, prototyping a service, or anything where a single container is enough, apple/container is ready and it’s lovely to use. The menu bar stays quiet.

For heavy Compose stacks, devcontainers, or workflows where production parity with a Docker-based CI is non-negotiable, Docker Desktop (or Colima, if you want to keep the docker CLI) is still the safer call.

My own setup: apple/container as the daily driver, Docker kept around for the occasional Compose-heavy project. That feels about right for mid-2026, and I suspect the gap narrows again before the year is out.