Apple Container 1.0.0 Lands With Per-VM Linux and a macOS 26 Floor

Apple shipped version 1.0.0 of container on June 9, 2026, ending a year of pre-release labels for its open-source Swift tool that runs Linux containers on Apple silicon Macs. The first stable build locks in a per-virtual-machine model that separates the tool from Docker Desktop, adds a new container machine command for long-lived Linux environments, and moves configuration from system properties into a TOML file.

The 1.0.0 release is the first stable baseline for the Containerization Swift package container draws on, and it drops the version-0 XPC application interface without a compatibility shim. Running container still asks for a Mac with Apple silicon and macOS 26. The project’s GitHub repository now lists more than 46,500 stars, with the community having forked it nearly 1,500 times.

What Apple Shipped in container 1.0.0

The release notes open on a short marker from the team: container is one year old. The headline addition is the new container machine command for Linux environments that survive across sessions. Earlier 0.x builds centered on containers spun up for a task and torn down once the work was done.

Alongside the new command, 1.0.0 swaps a config.toml file in for the older user-properties-backed system settings and removes the container system property get and set subcommands. The release also adds a container cp command for moving files between the host and a running container, answering a request that had sat open since the early days of the project. The team also fixed accounting errors in the system df disk-usage command. On the networking side, each IP-address lease is now tied to its XPC connection, which resolves an address leak that built up over time. The release rounds out with a –stop-signal option for container run and tidied help output across subcommands.

Output formatting for container, image, network, and volume ls and inspect commands now follows one consistent shape across JSON, YAML, and TOML. The release drops the version-0 XPC application interface outright. A subsequent release will add an API version field, the notes say, so clients and servers can negotiate compatibility. The Containerization Swift package that sits underneath container is still on a 0.x version, so its source API can shift before it commits to stability.

• Container machine command for long-lived Linux environments with tight host integration
• config.toml replaces the older user-properties-backed system settings, removing the container system property get and set subcommands
• Container cp command for moving files between the host and a running container
• –stop-signal option on container run, plus tidied help output across subcommands
• One consistent ls and inspect output shape in JSON, YAML, and TOML
• IP-address leases tied to XPC connections to fix an address leak that built up over time
• Accounting errors corrected in the system df disk-usage command

One VM Per Container

Container’s core architectural choice separates it from every previous way to run Linux on a Mac. Each Linux workload runs inside its own lightweight VM, drawing on macOS’s Virtualization framework through the Containerization Swift package rather than sharing a single Linux host.

Three containers, three kernels, three IP addresses. Sub-second start times come from vminitd, a small init system that runs as the first process inside the VM. vminitd exposes a GRPC interface over vsock so the host can configure the runtime and launch processes. Each container can also ship its own optimized Linux kernel configuration, built from the same Kata-derived source the package ships.

Two backend implementations sit behind the same public protocol. The shipping path on Apple silicon uses Apple’s Virtualization framework directly, with no extra binaries required. A second backend runs on Linux through cloud-hypervisor and KVM, kept available for nested-virt testing inside containers themselves. The integration test suite for the package runs inside an apple/container Linux VM with nested virtualization enabled, then exercises only the cross-platform scenarios that don’t depend on macOS-only types. The full suite is macOS-only for now.

What Breaks for Existing Users

Two of the 1.0.0 changes are flagged as breaking in the release notes, and they have no compatibility shim. The first is the configuration move: any script that called container system property get or container system property set has to switch to reading and writing values in config.toml, replacing the older UserProperty-backed system settings.

The second breaking change is the removal of the version-0 XPC application interface. Older clients that used version 0 to talk to the daemon will fail to connect. A follow-up release is expected to add an API version field so future clients and servers can negotiate compatibility with each other, the release notes say. Issues that cannot be reproduced on macOS 26 typically go unaddressed, the project’s README adds, so any team on macOS 15 or earlier is unsupported.

Where It Stacks Against Docker Desktop and OrbStack

Docker Desktop and OrbStack both still run a single Linux VM for all containers, the opposite design choice to Apple’s per-VM model. That single-VM shape is what lets those tools bundle a Docker Compose-style workflow, a persistent daemon, and a richer GUI surface.

Apple’s tool leans into Apple silicon specifics. Docker Desktop runs on Windows, Intel Macs, Linux, and Apple silicon, while container is Apple silicon and macOS 26 only. That narrower target keeps Apple’s container lean and lets it use Virtualization framework features directly, at the cost of no native Compose-style orchestrator and no first-party GUI.

The per-VM model has one clean property for single-container development: tear down the container and the VM disappears, with no shared host to clean up afterwards. For multi-container stacks the trade gets harder because container ships no first-party Compose-style orchestrator or GUI. The community has produced wrappers that imitate the Docker Desktop look and feel, and Compose-equivalent YAML runners exist in third-party repositories, though none of those are first-party today. The 1.1.0 release that followed 1.0.0 already covers a couple of those rough edges.

The licensing also diverges. Apple Container ships under Apache 2.0 and is free for commercial use. Docker Desktop is free for individuals and small businesses but a paid product under Docker, Inc.’s subscription terms for larger organizations. OrbStack sits between the two: free for individual use, with paid plans for teams. The choice increasingly turns on whether the team wants Apple’s per-VM model, Docker’s cross-platform reach, or OrbStack’s faster cold-start and lower resource use on the same shared-VM design.

The Community Has Already Voted

The simplest signal of developer interest is the star and fork count. Apple Container’s GitHub repository lists more than 46,500 stars and nearly 1,500 forks as of the 1.0.0 release window. The container CLI crossed 1.0.0 exactly a year after the project’s first appearance on GitHub. The release cadence stayed roughly monthly through the 0.x line, with each pre-release adding a piece of the architecture that 1.0.0 now freezes.

The post-1.0.0 trajectory is already busy. Version 1.1.0 followed 1.0.0 with fixes for Unix domain socket mounts in non-root containers and for container cp behavior with relative source paths. The next visible work centers on the container machine feature and the eventual versioned XPC API. The Containerization Swift package is still on a 0.x version, so its source API can shift.

• more than 46,500 GitHub stars on apple/container
• nearly 1,500 forks on the same repository
• 1.1.0 released after 1.0.0, with Unix-domain-socket and container-cp fixes
• Exactly one year between the project’s GitHub debut and the 1.0.0 tag

Frequently Asked Questions

When did Apple Container 1.0.0 ship?

Apple released container 1.0.0 on June 9, 2026, one year after the project’s appearance at WWDC 2025. The release notes call out the date alongside the new container machine command and two CLI breaks.

What is the new container machine command?

container machine is a new command in 1.0.0 for long-lived Linux environments that survive across sessions. Earlier 0.x releases focused on containers spun up for a task and torn down, so the new command is the first step toward persistent Linux surfaces on the Mac. The full Apple container release history lists the change under the 1.0.0 highlights.

Does Apple Container 1.0 require macOS 26?

Yes. container is supported on macOS 26 and uses new virtualization and networking features introduced in that release. The README is direct that issues not reproducible on macOS 26 typically go unaddressed, and the tool is not designed for Intel Macs and does not support older macOS releases. Apple’s container CLI source repository lists the requirement at the top of the install section.

Is Apple Container a Docker Desktop replacement?

Apple Container is an open-source alternative for local Linux development on Apple silicon, built for single-container workflows rather than full Docker Desktop use. Docker Desktop retains Windows, Intel Mac, and Linux support plus a permanent daemon and Compose, while container has no permanent daemon and no first-party Compose replacement. The per-VM isolation model is the main reason developer teams are trying it alongside an existing Docker install.

What breaks in my existing scripts?

Two changes flagged breaking in the 1.0.0 release notes. The container system property get and set subcommands are gone, replaced by reading and writing a config.toml file. The version-0 XPC application interface is removed without a compatibility layer, so any client built against it has to move to the new interface or wait for a future versioning release. Apple’s Containerization Swift package source tracks the API surface that those clients use.