Apple Just Killed Docker Desktop on Mac - Inside Apple's Container 1.0
For years, running a Linux container on a Mac meant Docker Desktop, one giant Linux VM running in the background, and a fan that kicked in every time you ran docker compose up.
Apple just changed that. Container 1.0 is out. It’s open source, written in Swift, and built for Apple silicon. And it works differently enough that calling it “just another Docker” misses the point.
It’s also free. Container ships under the Apache 2.0 license and has already passed 40,000 stars on GitHub.

What Container actually is
Container is a command-line tool that creates and runs Linux containers on your Mac. It uses standard container CLI syntax, so if you know Docker commands, you already know how to drive it:
container run --rm -it ubuntu:latest bash
It’s fully OCI compatible. You can pull any image from Docker Hub, GitHub Container Registry, or anywhere else, and push images you build back to any standard registry to run them on another machine.
The difference is underneath. Docker Desktop runs all your containers inside one shared Linux VM. Apple went the other way: every container runs as its own lightweight VM, started on demand through the virtualization stack in macOS 26.
You’d think that would be slower. It isn’t, because Apple got VM startup down to under a second. So you get the isolation of a real VM that feels almost like a native process.
Why this matters on Apple silicon
A few things come out of that design. Each container is its own VM with its own kernel, so workloads can’t see each other. There’s no always-on VM sitting in the background eating your RAM either; containers spin up when you need them and disappear when you’re done. Because it’s written in Swift and tuned specifically for Apple silicon, images run natively on arm64 with no emulation tax, and it ends up faster and lighter than anything Docker Desktop does on a Mac. And since the whole thing is built on the open-source Containerization package, you can actually read how it works and build on top of it.
So did Apple kill Docker Desktop?
For the everyday case, spinning up a container to test something, run Postgres locally, or reproduce your CI environment, Container does the job, and it does it without the weight Docker Desktop carries. If that’s most of what you do, you might genuinely not need Docker Desktop anymore.
But “killed” is a strong word, and a few things stop it from being a clean swap today. It only runs on Apple silicon, so Intel Macs are out. It doesn’t ship the years of tooling built around Docker Desktop, so Compose, the GUI, and registry integration are things you’ll either miss or wire up yourself. And it’s macOS only, which solves your Mac problem but not your Linux CI runner or your teammate on Windows.
So the headline is half true. Apple didn’t delete Docker. It removed the main reason a lot of us put up with Docker Desktop in the first place: a heavy, always-running VM just to get one Linux container onto a Mac.
Try it yourself
If you’ve got an Apple silicon Mac, it’s worth ten minutes. Grab the release from the project page or straight from the GitHub repo, then:
container system start
container run --rm hello-world
Pull an image, run a shell, kill it, and notice how little it leaves behind.
My take
I don’t think Apple set out to “beat” Docker. This is just Apple being Apple: it looked at a slow, bolted-on experience on its own platform and rebuilt it natively, in Swift, tuned for its own chips.
Call it a Docker killer or call it the Mac finally getting containers right. Either way, running Linux containers on a Mac just got a lot lighter.