Apple’s container Just Hit v1.0.0

Apple’s container has finally reached v1.0.0.

The name is a bit too generic, so in this article I’ll call it Apple’s container.

At first glance, it is tempting to describe it as “Apple’s Docker.” But that is not quite accurate. Apple’s container is a CLI tool for creating and running Linux containers as lightweight virtual machines on macOS. It is written in Swift, optimized for Apple silicon, and works with OCI-compatible container images, so it can pull images from standard registries and push images that you build yourself. The GitHub repository currently lists 1.0.0 as the latest release, dated June 9, 2026. (GitHub)

I have not used it heavily in production yet, so this is mostly a documentation-based first look rather than a deep hands-on review.

What is Apple’s container?

Apple’s container is a tool for running Linux containers on a Mac.

The official README describes it as a tool that lets you create and run Linux containers as lightweight virtual machines on macOS. It consumes and produces OCI-compatible container images, which means the workflow should feel familiar if you already use Docker, Podman, or other OCI-based tools. (GitHub)

For example, the basic commands look very Docker-like:

container run -it ubuntu:latest /bin/bash
container build -t my-app:latest .
container image pull alpine:latest

The command reference includes familiar operations such as container run, container build, container create, container exec, container logs, container start, and container stop. It also supports options such as volume mounts, memory/CPU configuration, port publishing, Rosetta support, and SSH agent forwarding. (GitHub)

It has a Docker-like CLI, and it understands OCI images, but it is not a Docker daemon-compatible implementation. It is a different implementation built around Apple’s Containerization framework and macOS virtualization technologies.

container machine: the interesting part

One of the most interesting features is container machine.

A normal application container is usually modeled around one process or one application. A container machine, on the other hand, is modeled more like a persistent Linux environment on your Mac.

Apple describes container machines as fast, lightweight, persistent Linux environments based on standard OCI images. They also provide host integrations such as automatic username and home directory sharing. (GitHub)

For example:

container machine create alpine:latest --name dev
container machine run -n dev

This gives you a Linux environment that is closer to a small development machine than a one-shot container.

Your macOS home directory can be mounted inside the container machine, so you can edit code with your Mac editor or IDE while building and running the project inside Linux. Apple’s docs describe this as “edit on the Mac, build inside.” (GitHub)

It can also run the image’s init system. If the image includes systemd, you can run services such as PostgreSQL using commands like:

systemctl start postgresql

Apple’s documentation explicitly calls out this use case for testing real Linux services inside a container machine. (GitHub)

This feels less like “Docker replacement” and more like a Mac-native WSL-like Linux development environment.

That is probably the part I am most interested in.

Can it replace Docker Desktop?

For some workflows, maybe.

For many real-world team workflows, probably not yet.

Docker Desktop is not just a container runner. Docker’s documentation describes Docker Desktop as an application for Mac, Linux, and Windows that lets you build, share, and run containerized applications. It includes Docker Engine, Docker CLI, Docker Build, Docker Compose, Docker Scout, and Kubernetes. (Docker Documentation)

Apple’s container covers an important subset of that world:

It can run containers.
It can build OCI images.
It can pull and push images.
It has familiar container lifecycle commands.
It integrates nicely with Apple silicon and macOS.

But it does not look like a drop-in Docker Desktop replacement.

The biggest practical gap for many developers is Docker Compose. A lot of local development environments are built around docker compose up, especially for apps that need a database, Redis, background workers, and multiple services.

There is a third-party project called container-compose, and Homebrew also has a container-compose formula, but that still means relying on a non-Apple bridge for a very central part of many workflows. (Homebrew Formulae)

For single containers, isolated experiments, image builds, and lightweight Linux dev environments, Apple’s container looks very promising.

For Compose-heavy development environments, Docker Desktop is still the safer default.

The biggest architectural difference

The biggest difference between Docker Desktop and Apple’s container is how they use virtual machines.

macOS does not have a Linux kernel. So if you want to run Linux containers on a Mac, some kind of Linux environment is required.

Docker Desktop for Mac uses a Linux VM to run containers. Docker’s documentation says Docker Desktop supports multiple Virtual Machine Managers to power the Linux VM that runs containers. (Docker Documentation)

Conceptually, Docker Desktop looks like this:

Docker Desktop for Mac:

macOS
  └─ Linux VM
       ├─ container A
       ├─ container B
       └─ container C

Apple’s container takes a different approach.

Instead of putting many containers inside one shared Linux VM, it runs a lightweight VM for each container. Apple’s technical overview says this gives each container VM-level isolation, lets the user mount only the necessary host data into each VM, and aims for memory usage lower than full VMs with boot times comparable to containers inside a shared VM. (GitHub)

Conceptually:

Apple container:

macOS
  ├─ lightweight VM ─ container A
  ├─ lightweight VM ─ container B
  └─ lightweight VM ─ container C

That design is very Apple-like.

It keeps the container workflow, but moves the isolation boundary closer to a VM boundary. This is attractive for security and privacy, especially when running code you do not fully trust.

At WWDC, Apple also described Containerization as running each container inside its own lightweight VM while still providing sub-second start times. Each container can also get its own dedicated IP address, which can remove the need for individual port mappings in some cases. (Apple Developer)

Of course, there are trade-offs.

Apple’s technical overview notes that memory pages freed inside a container VM are not always returned to the macOS host. If you run many memory-intensive containers, you may need to restart them occasionally to reduce memory usage. (GitHub)

So I would not assume this is automatically lighter than Docker Desktop for every workload. It needs real-world testing.

Docker-like, but not Docker-compatible

The CLI looks familiar, but compatibility is not the same thing as similarity.

For basic usage, you might imagine something like this:

alias docker='container'

And for simple commands, that may feel surprisingly natural.

But the broader Docker ecosystem is not just the CLI shape. Many tools expect the Docker Engine API, the Docker socket, or Docker Compose behavior.

There is already a GitHub issue asking Apple’s container to expose the Docker Engine API through something like /var/run/docker.sock, and that issue is marked “Closed as not planned.” (GitHub)

Another issue requesting Moby API support says that such support would be a prerequisite for Docker Compose to support Apple’s runtime, but that issue is marked as a duplicate. (GitHub)

So at least right now, I would not think of Apple’s container as a Docker Desktop drop-in replacement.

OS support

The official README says you need an Apple silicon Mac to run container, and that macOS 26 is the supported target because the project relies on new virtualization and networking features in that release. (GitHub)

Homebrew already provides

brew install container

The Homebrew formula lists stable version 1.0.0, requires arm64 architecture, and lists macOS 15 or newer as a requirement, with Xcode 26 or newer required for building. (Homebrew Formulae)

There is an important nuance here.

Apple’s technical overview says container can run on macOS 15, but with functional and user-experience limitations. For example, macOS 15 has limitations around network isolation, multiple networks, and container IP addresses. The container network commands are not available on macOS 15. (GitHub)

So the cleanest experience seems to be macOS 26 on Apple silicon.

Why this matters on macOS

On Linux, containers run on the host Linux kernel using features such as namespaces and cgroups.

On macOS, that is not possible directly because macOS is not Linux.

That is why Docker Desktop, Colima, Rancher Desktop, Podman Machine, and now Apple’s container all have to solve the same core problem:

How do we provide a Linux environment on a Mac without making the developer experience terrible?

Docker Desktop solves this with a managed Linux VM and a polished Docker ecosystem around it.

Apple’s container solves it by making lightweight VMs part of the container abstraction itself.

That distinction matters.

Docker Desktop optimizes for compatibility with the existing Docker ecosystem.

Apple’s container appears to optimize for Apple-platform integration, isolation, and a cleaner VM-per-container model.

Where Apple’s container could be useful

I see three strong use cases.

1. Running single containers on Mac

For quick experiments, sandboxing, and running one-off Linux tools, Apple’s container could be very convenient.

container run -it ubuntu:latest /bin/bash

If you do not need Compose, Kubernetes, or deep Docker ecosystem compatibility, this might be enough.

2. A Mac-native Linux development environment

This is where container machine gets interesting.

You can keep using your Mac editor, your Mac terminal, your Mac tools, and still build or test inside a real Linux environment.

This could become a really nice “WSL for Mac” experience.

3. Local sandboxing for untrusted code

Because each container runs inside its own lightweight VM, Apple’s container may be a good fit for running code with stronger isolation than a regular shared-kernel container.

That could be useful for local experiments, CI-like testing, or even AI coding agents that need to run generated code in a safer environment.

I would not call it a complete security solution by itself, but the direction is interesting.

Conclusion

Apple’s container reaching v1.0.0 is a big milestone.

I do not think it means everyone should uninstall Docker Desktop today.

Docker Desktop is still the more complete environment if your workflow depends on Docker Compose, Kubernetes, Docker Engine API compatibility, or existing tools that expect the Docker socket.

But Apple’s container is important because it gives macOS developers an official Apple-native option for running Linux containers.

Docker Desktop usually runs multiple containers inside a shared Linux VM.
Apple’s container runs each container inside its own lightweight VM. (GitHub)

That makes Apple’s approach especially interesting for isolation, privacy, and sandbox-style workflows.

Personally, the feature I am most excited about is not the Docker-like CLI itself. It is container machine.

The idea of having a persistent Linux development environment that integrates naturally with macOS, shares my home directory, lets me edit on the Mac, and build inside Linux feels very promising.