Apple Ships Stable 1.0 of its Native Container Tool for macOS

Apple just gave macOS developers a real reason to rethink how they run Linux containers.

Apple’s container project hit version 1.0.0 on June 9, 2026, a year after it was first introduced at WWDC 2025. That version number is a bigger deal than it looks. Every release before this one carried breaking changes, so putting it into daily use was a gamble. That’s no longer true.

What Container Actually Does

Container is Apple’s own tool for running Linux containers on a Mac, with each container running in its own lightweight virtual machine. It’s written in Swift and built for Apple silicon. From the command line, you can create, run, build, and publish Linux containers directly on macOS.

It’s also fully OCI-compatible. Images from Docker Hub work without changes, and anything you build with it pushes to any standard OCI registry. Your existing image library doesn’t need to change to use it.

The Architecture is the Real Story

Running Docker on a Mac has always meant running a Linux VM under the hood, since containers are a Linux kernel feature and macOS doesn’t have that kernel. Docker Desktop’s approach has been a single shared VM, with every container running inside it.

Apple took a different path. Each container gets its own dedicated, lightweight micro-VM, launched through the macOS Virtualization framework. Apple silicon can start and stop these fast enough that it doesn’t feel like a tradeoff. The per-container VM model isn’t new — OrbStack proved it out first — but Apple shipping it as an officially maintained, open-source tool built into macOS is new.

Mitch Ashley, VP and practice lead for software lifecycle engineering and AI-native software engineering at The Futurum Group, sees this as a meaningful shift in where the security boundary sits. “The container isolation boundary on Apple silicon is moving from the shared kernel namespace to the hypervisor,” Ashley said. “Apple shipped the per-container micro-VM model OrbStack proved out, now maintained and open source, resolving a shared-VM limit Docker carried for years.”

That matters beyond the architecture diagram. “Teams executing AI-generated code on developer machines gain a boundary where a container escape must clear a hypervisor,” Ashley said. “One VM per container is the more manageable and defensible way to run untrusted workloads on Apple silicon.”

That’s a real consideration now that more developers are running AI agents that execute generated code locally. A compromised container can’t reach anything outside its own VM.

What’s New in 1.0

The biggest addition is the container machine command, which creates a persistent Linux environment instead of a short-lived, single-process container. It automatically maps your macOS username and home directory into the Linux environment, so your repos and dotfiles are available on both sides. You can write code in your usual macOS editor and run it inside a real Linux environment without extra setup. The release also added a container cp command for moving files between the host and the container and moved the configuration to TOML files.

Where it Still Falls Short

Apple Container isn’t a Docker Desktop replacement yet, and Apple hasn’t pretended otherwise. There’s no Compose support. With Docker Desktop or OrbStack, spinning up a multi-service app is one command. With Apple Container, you’re either wiring it together manually or waiting on third-party bridges that aren’t mature yet. Compose support is the most active thread in the project’s GitHub community, with over 150 replies and no timeline from Apple.

The performance tradeoffs are worth knowing, too. Independent benchmarks found Apple Container beating Docker Desktop in memory throughput by about 33%, but Docker Desktop wins in cold-start latency by roughly 4x. If you’re in a tight test-and-rebuild loop, that difference shows up. Small-file I/O also lags, since each container gets its own filesystem — that adds overhead when you’re installing something like npm packages with tens of thousands of small files.

There’s a platform ceiling as well. Full functionality requires an Apple Silicon Mac running macOS 26, since container-to-container networking depends on APIs available only on that platform. Intel Macs aren’t supported at all, and teams managing a fleet of Macs on an older OS policy won’t get the full experience anytime soon.

What This Means for IT Teams

Nobody needs to drop Docker Desktop this week. It still has the broader ecosystem, Compose workflows, and GUI tooling that Apple Container doesn’t. But the direction is clear. Apple shipped a stable 1.0, open-sourced the project, and is treating containers as a core part of its developer platform. For single-container workloads on Apple silicon, or for teams that want hardware-level isolation without Docker Desktop’s per-seat licensing, this is worth piloting now. For anyone running complex, multi-service local environments, keep an eye out for Compose support and check back in a few months.