Apple Container 1.0: Native Linux Containers on macOS 26 (Swift, OCI, Apple Silicon)

TL;DR: Apple container 1.0.0 shipped June 9, 2026 — the first stable release of Apple's Swift-native tool for Linux containers on Apple silicon. The apple/container repo has 42K+ GitHub stars, runs OCI-compatible images in lightweight VMs (not shared-kernel tricks), requires macOS 26, and adds container machine for persistent Linux dev environments. It is Apple's answer to "run Linux on Mac natively" without Docker Desktop — open source under Apache 2.0.

Why Apple container matters in 2026

Mac developers have lived on Docker Desktop, Colima, OrbStack, and remote Linux VMs for a decade. At WWDC 2025, Apple open-sourced a preview; on June 9, 2026, 1.0.0 marked production-ready in Apple's framing.

The pitch is simple:

• Native — Swift CLI + Apple's Virtualization framework on Apple silicon
• Standard — pull/push OCI images from any registry
• Isolated — VM-per-container architecture (The New Stack compares this to Docker's shared-kernel model on Mac)
• Free — no Docker Desktop subscription; Apache 2.0 source

Architecture: VM-per-container, not "Docker with a new logo"

Apple's design choice is the headline technical difference.

Traditional Docker on Mac historically ran Linux containers inside a single Linux VM (or shared runtime), with bind mounts and networking layered on top.

Apple container runs each container in its own lightweight VM via the Virtualization framework. That trades some overhead for stronger isolation and tighter integration with macOS 26 networking and virtualization APIs.

Two layers to know:

1. container CLI — what you install and type in Terminal (command reference)
2. Containerization — the Swift package handling OCI images, execution, and init (apple/containerization)

Apple also uses the Swift Static Linux SDK for cross-compiling static Linux binaries from macOS — relevant if you ship Swift server apps into containers (DevClass hands-on).

What's new in 1.0.0

The 1.0.0 release notes highlight:

container machine — persistent Linux environments

The flagship 1.0 feature: long-lived Linux VMs with host integration — mount macOS directories, map user/working directory automatically, run an init system. container machine run opens a terminal in the default machine.

Think WSL for Mac, but OCI-native: DevClass and Sean Kim's WWDC recap both frame it that way.

Apple demoed the workflow: edit in Xcode on macOS → build/test in Linux → hit the server from Safari.

System configuration via TOML

UserDefault-backed container system property get/set is removed. System config moves to a TOML file (PR #1425) — better for dotfiles and CI.

Other 1.0 polish

• Structured JSON/YAML/TOML output for ls and inspect on containers, images, networks, volumes
• --stop-signal for container run
• Breaking: dropped compatibility with 0.x XPC API major versions

Install and first run

From the official README:

Requirements

• Apple silicon Mac (Intel not supported for this tool)
• macOS 26 — maintainers target issues reproducible on 26 only

Initial install

1. Download the signed installer package from GitHub Releases
2. Double-click the .pkg — installs under /usr/local (admin password required)
3. Start the system service:

container system start

Upgrade

container system stop
/usr/local/bin/update-container.sh
container system start

Downgrade example

container system stop
/usr/local/bin/uninstall-container.sh -k
/usr/local/bin/update-container.sh -v 0.3.0
container system start

Uninstall

/usr/local/bin/uninstall-container.sh -d   # remove tool + user data
/usr/local/bin/uninstall-container.sh -k   # remove tool, keep data

Day-one workflow (OCI-familiar)

If you know Docker, the muscle memory transfers:

# Start the runtime (once per boot/session as needed)
container system start

# Pull a standard OCI image
container image pull docker.io/library/nginx:latest

# Run a container
container run --rm -p 8080:80 docker.io/library/nginx:latest

# Persistent Linux dev environment (1.0 feature)
container machine run

Images from Docker Hub, GHCR, or private registries that speak OCI work — you are not locked to Apple's registry.

Guided tutorial: build, run, and publish a web server image in the repo docs.

Apple container vs Docker Desktop vs OrbStack

Practical take: Switch solo or Apple-heavy teams doing Linux CI parity on Mac should try 1.0. Teams deep on Docker Compose, Kubernetes desktop, or Intel Macs should not rip out Docker yet.

Who should use it now

Good fit:

• Apple silicon developers on macOS 26
• Swift/server devs (Vapor, Hummingbird) testing Linux builds locally
• Security-sensitive workflows wanting VM isolation per container
• OSS contributors who want Apache-licensed tooling without Docker Desktop

Wait or keep Docker:

• macOS 15 or Intel hardware
• Production parity depends on docker compose files with complex networking
• Windows/Linux teammates need identical local runtime

Project status and stability

The README still notes active development: stability is guaranteed within patch versions (1.0.x). Minor releases may break until the ecosystem matures post-1.0.

With 42K+ stars, 99 contributors, and 16 releases in roughly a year since the repo was created (May 2025), adoption velocity is real — but 1.0.0 is a milestone, not the end of churn.

Docs: apple.github.io/container/documentation/

Connection to agent and AI dev workflows

Local containers power MCP servers, eval harnesses, and sandboxed agent runs. A native Mac runtime reduces friction for developers running Claude Code, Cursor agents, or self-hosted tool loops against Linux-only dependencies — without paying Docker Desktop tax on every laptop.

Apple container does not replace cloud sandboxes (Cloudflare temporary accounts, etc.) — it replaces local Linux parity.

Related reading

• Context Mode MCP sandbox for agents
• Terminal Bench 2.0 — evaluating coding agents
• Self-Harness — agents improving their own framework

Primary sources: apple/container · 1.0.0 release · Containerization package · The New Stack comparison · DevClass hands-on

Version numbers, star counts, and macOS requirements accurate as of June 25, 2026. Verify against the GitHub README before production rollout.