Apple’s new "Container" Engine (Bye Docker?)

Hands-on review of Apple's new container framework announced at WWDC 2

Apple just dropped something no one expected at WWDC (their annual developer conference) with the announcement of their own containerization framework for macOS.
And yes, everyone's asking the same question: is this the end of Docker Desktop and Podman on macOS? These are two popular alternatives that developers use to run local linux containers today.

Let's dive into what Apple has built, explore its features and current limitations, and get our hands dirty with some actual code examples.

If you prefer watching over reading :

Meet "Container" (yes, that's really the name)

I have to say, Apple's developers aren't quite as creative as their marketing team when it comes to naming. The project is simply called Container, though if you check their official announcement page, it's referred to as the "Containerization Framework."

The framework consists of two main repositories:

• Containerization: The core virtualization engine

• Container: The CLI tool that developers will use to create and manage lightweight VMs

One fun fact that caught my attention: I know for certain that Apple actually hand-wrote this code because a PR was submitted to fix typos in variable names and comments - something an AI agent will never do 😅

Kudos to Apple for the handcrafted code 👏

The new architecture: one Virtual Machine (VM) per container

The framework is built as an open-source Swift framework, released under the Apache 2.0 license. This is particularly interesting, considering Docker Desktop has not been free for commercial use for some time. If you’re using Docker Desktop at work, you probably owe Docker some money.

Docker Desktop is free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.

The new architecture: one Virtual Machine (VM) per container

Here's where things get really interesting. A traditional container engine like Docker Desktop runs one large Linux virtual machine in the background, even when no containers are running. All your containers share this single VM, which can introduce security risks since files must pass through the shared virtual machine before reaching your container.

Traditional container engine like Docker Desktop

Apple's approach is fundamentally different: each container gets its own dedicated virtual machine. This provides:

• Strong security isolation

• Complete container separation

• Individual IP addresses for each container

Apple’s container framework

That last point is nice - no more port forwarding headaches! You can access your local web services directly via the container's IP address.

Apple claims startup times are within seconds, which is pretty impressive for full VM isolation.

But let's confirm this and run the thing.

Installing Container on macOS

To install it, you can simply install the package installer file (.pkg) on their release notes page

Once done, you will first have to launch the service by :

container system start

If you are familiar with Docker for Desktop or Podman, you'll feel right at home as commands are pretty similar. And yes, it does support building from Dockerfile

$ container --help
OVERVIEW: A container platform for macOS

USAGE: container [--debug] <subcommand>

OPTIONS:
  --debug                 Enable debug output [environment: CONTAINER_DEBUG]
  --version               Show the version.
  -h, --help              Show help information.

CONTAINER SUBCOMMANDS:
  create                  Create a new container
  delete, rm              Delete one or more containers
  exec                    Run a new command in a running container
  inspect                 Display information about one or more containers
  kill                    Kill one or more running containers
  list, ls                List containers
  logs                    Fetch container stdio or boot logs
  run                     Run a container
  start                   Start a container
  stop                    Stop one or more running containers

IMAGE SUBCOMMANDS:
  build                   Build an image from a Dockerfile
  images, image, i        Manage images
  registry, r             Manage registry configurations

SYSTEM SUBCOMMANDS:
  builder                 Manage an image builder instance
  system, s               Manage system components

To pull an image, you would do :

container image pull python:3.12

And to run for instance a python shell within the above image :

container run -it python:3.12 python

Current limitations

Before you get too excited, there are some important caveats. The framework is designed primarily for macOS 26 (the upcoming 2025 fall release, still in beta as the time of this writing), though it works on macOS 15 with limitations.

Yes, the version jump from macOS 15 to 26 is definitely confusing. Apple decided to align macOS version numbers with the current year. The transition might sound even more confusing at first, but it will make more sense over time—you’ll be able to tell which year the OS is from just by its version name!

Key limitations as of now on macOS 15 :

• Container-to-container networking isn't fully supported yet. This is a major limitation if you're running multi-container setups like a web server with a database.

• Container IP Address Management : there are still some rough edges around how container IP addresses are handled and accessed.

Performance comparison: Container vs Docker Desktop

I ran some quick tests comparing Container with Docker Desktop by running a simple Python shell through a python:3.12 image, and the results were interesting:

Surprisingly, pulling images was noticeably faster with Docker for Desktop compared to Container. I'm not entirely sure why, but one reason was probably because I had some layers already cached on the Docker local registry.

Looking at Activity Monitor:

Docker Desktop:

• Large shared VM consuming ~3.5GB RAM

• Multiple background processes

• Consistent CPU usage even when idle

  Apple Container:

• Smaller individual VM footprints ~ 200MB RAM per container

• Lower baseline resource usage

• More efficient per-container resource allocation

However, keep in mind that Docker’s shared VM model means the overhead is amortized across all containers. With Apple’s approach, each container incurs its own overhead—but in practice, this is usually still lower than the Docker Desktop engine, since most developers typically run only 2–3 containers at a time.

Exciting but early

Apple's containerization framework represents a great approach to linux container isolation on macOS. The performance benefits and security improvements are nice, especially the individual VM architecture and direct IP addressing.

However, it's still very early days. The missing multi-container networking, uncertain Docker Compose support, and devcontainer integration (for VSCode/Cursor) questions make it hard to recommend for use today.

That being said, I expect these feature gaps to be filled by the time macOS 26 reaches general availability—so let’s take it for another test drive in a few months!