Apple has quietly released a new open-source project that could significantly shift how containers are run on macOS. Simply named container, it introduces a Swift-powered, Apple-native container runtime designed specifically for macOS systems, especially those running on Apple Silicon.
At its core, container allows users to pull, build, run, and push standard OCI-compliant Linux containers. However, unlike Docker, which typically relies on a shared virtual machine for all containers on macOS, Apple’s approach runs each container in its own lightweight micro-VM, complete with an isolated Linux kernel and network stack. According to the project’s GitHub Page:
The tool consumes and produces OCI-compliant container images, so you can pull and run images from any standard container registry. You can push images that you build to those registries as well, and run the images in any other OCI-compliant application.
This model mirrors the concept of microVMs popularized by tools like Firecracker, but it’s been tightly integrated into macOS through the Virtualization.framework, Apple’s native hypervisor interface.
While Apple is not branding this as a full-blown replacement for Docker, the tool does cover much of the same ground for local development use cases. The CLI is familiar and approachable: with commands like container image pull alpine, or container run -ti alpine sh.
What sets this tool apart is its seamless integration into the macOS operating system itself. Rather than emulating a Linux environment with external tools, Apple’s solution uses Swift for much of its userland, including a tiny init system named vminitd that boots containers in a matter of milliseconds.
The project also includes a Swift package, “Containerization,” which exposes low-level APIs for managing images, volumes, networking, and boot processes, offering advanced users and tool builders a powerful foundation.
Okay, so far, so good, but now, let me share a few thoughts of my own on the subject. Honestly, I’m a little confused by this move from Apple. And I’ll explain why right away.
First, let’s get one thing straight—there’s no such thing as true native containerization on any operating system other than Linux, and there’s a simple reason for that. Docker relies on Linux-specific kernel features like cgroups, namespaces, and overlay filesystems, which the macOS kernel can’t provide.
For that reason, the new Apple project uses a separate lightweight Linux VM to run every single container. At the same time, Docker’s approach is to run everything inside a single virtual machine (built with LinuxKit) that hosts the Docker Engine and all containers.
So, in Apple’s case, each container is in its own separate VM, which means a lot of VMs (no matter how lightweight they are), which doesn’t seem like the most efficient approach.
On the flip side, separate VMs do have some benefits. For example, one key advantage of Apple’s new project is that it gives each container its own dedicated Linux kernel, unlike Docker, which shares a single kernel across all containers (you cannot mix kernel versions per container).
Moreover, it also uses the native macOS network stack, while Docker typically relies on a virtual machine with NAT or bridged networking. To help make this clearer, I’ve put together a quick comparison table:
| Feature | Docker Desktop | Apple Container |
|---|---|---|
| VM model | Shared VM for all containers | Micro‑VM per container |
| Kernel | Single Linux kernel for all | Dedicated Linux kernel per container |
| Base | Uses Docker Engine and hypervisor (e.g. qemu or HyperKit) | Uses Apple’s own Virtualization.framework |
| Networking | NAT or bridge via VM | Native macOS network stack (with limitations in early versions) |
| Runtime | runc / containerd | vminitd, a custom Swift init system |
| Integration | Cross-platform and container-focused | Deeply macOS-native and Swift-centric |
Despite all the differences, the core idea is the same in both cases—building, running, and working with OCI-compliant container images. From that perspective, Docker still offers way more flexibility and capabilities than Apple’s new project.
For example, there’s no docker-compose equivalent yet, and the tooling ecosystem (e.g., no GUI dashboard, limited orchestration) still needs to be developed and improved.
So, I wonder why Apple put all this effort into creating this. Aside from “Made by Apple,” they seem to want to get their share from this massive niche, almost entirely dominated by Docker, by offering better macOS integration, using system-native APIs instead of third-party daemons, and eventually, better security isolation, which reduces attack surface.
Since the project is still in its early days, it’ll be interesting to see how it evolves—and whether it can live up to Apple’s expectations by eventually replacing Docker or Podman as the go-to container tool for developers on macOS.
