Apple's container tool: Linux VMs on macOS 26, Swift-built, OCI-compatible

What problem it solves and who it targets

The container tool solves a specific mismatch: developers on Macs who want to run Linux containers without a full desktop VM or a Docker daemon. It creates and runs containers as lightweight virtual machines, using the virtualization and networking features new in macOS 26. The target user is an Apple silicon Mac owner on that specific OS release. The README is explicit: older macOS versions are not supported, and maintainers will not address issues that cannot be reproduced on macOS 26. That makes it a forward-looking tool, not a compatibility layer. If you are on an older macOS release, this tool is not for you, regardless of how well it works elsewhere.

OCI images as the interchange format

Container consumes and produces OCI-compatible images. That means you can pull from any standard registry, run the image, and push images you build back to the same registries. The images are not locked to Apple's format. This is a strong interoperability choice. The README says you can run the images in any other OCI-compatible application. The practical effect is that a developer can build an image with container, push it to Docker Hub or a private registry, and later run it on a Linux server. The tool does not invent a new image format. It relies on the Open Container Initiative image spec, which is a mature standard. The low-level management is delegated to the Containerization Swift package, also from Apple, which handles image, container, and process details.

The system service and the run command

The tool installs a system service that you start explicitly. The README shows the command container system start after installation. You control the lifecycle. To run a container, the example is container run --rm alpine echo hello. That command pulls the alpine image, boots a lightweight Linux VM, runs echo, prints hello, and removes the container on exit. The --rm flag is familiar from Docker, and the workflow will feel natural to anyone who has used Docker or Podman. The fact that it is a system service suggests the VM runtime is persistent across invocations, though the README does not detail the internal architecture. That is a gap: the README does not explain how the service manages multiple concurrent containers or how it handles resource limits.

Installation, upgrade, and downgrade paths

Installation is via a signed installer package from the GitHub releases page. You double-click, enter an administrator password, and files go under /usr/local. The system service must be started manually. Upgrades use a script installed to /usr/local/bin: /usr/local/bin/update-container.sh. Before upgrading or downgrading, you must stop the service with container system stop. For downgrades, the README shows uninstalling first with /usr/local/bin/uninstall-container.sh -k, which keeps user data, then running update-container.sh -v 0.3.0 to install a specific version. The -d flag removes user data during uninstall. These scripts are a pragmatic approach for a tool under active development. They give you a deterministic way to move between versions, which is useful given the stability caveat. The update script is a concrete artifact you can inspect before running.

Stability guarantees and the pre-1.0 caveat

The Project Status section is the most important part of the README for planning upgrades. It says release versions are product versions, not semantic versions. CLI compatibility generally preserves backward compatibility within a major release, though there may be the odd case where breaking compatibility is necessary, and features marked experimental (for example the cluster subcommand) may change without a compatibility guarantee. The container-apiserver XPC API preserves forward and backward compatibility within a major version, but other non-public XPC helpers do not guarantee CLI or API compatibility across versions. Application data provides forward compatibility only, guaranteed within one major version, and upgrading to a newer major version may require a specific upgrade path. The current releases are 1.6.1, 1.6.0 and 1.5.0. For a tool that runs as a system service, that is a meaningful operational risk, so pin versions and test upgrades carefully.

A genuine limitation: macOS 26 only and no older OS support

The hard requirement for macOS 26 is a genuine limitation. The README states that container is supported on macOS 26 because it takes advantage of new virtualization and networking features in that release. It does not support older versions, and maintainers will not address issues that cannot be reproduced on macOS 26. This means the tool is unusable on any Mac still running an older macOS release. It also means that if your organization standardizes on an older OS for compliance or stability, container is the wrong tool. The limitation is not a bug; it is a design choice to leverage new OS features. But it is a hard boundary. You cannot work around it with a compatibility layer. The only path is to upgrade to macOS 26, which may not be an option for every team.

Alternative: Docker Desktop or Podman with a different architecture

The obvious alternative is Docker Desktop, which runs Linux containers on a Mac using a lightweight VM but does not require macOS 26. Docker Desktop uses a LinuxKit-based VM and a client-server architecture; it is not written in Swift and is not tied to a specific macOS release. Podman is another alternative, with a daemonless design and support for rootless containers. The key difference is that container is Apple's own tool, built on Apple's Containerization package, and it leverages macOS 26-specific virtualization features. Docker Desktop and Podman are cross-platform and support older macOS versions. If you need to support a fleet of Macs on different OS versions, one of those tools is a better fit. If you want a first-party tool that aligns with Apple's roadmap and you are on macOS 26, container is the option to evaluate.

Maintenance and upgrade cost, licensing, and what to verify

The upgrade cost is managed through scripts, but the process requires stopping the service, running the update script, and restarting. That is a manual step, not an automatic background update. The uninstall script with -k preserves user data, which is useful for testing downgrades. The license is Apache-2.0, which is permissive and allows commercial use, modification, and distribution, with no copyleft obligations. The project is under active development, and the README says CLI compatibility is generally preserved within a major release, with experimental features excepted. Before adopting, check the current release, 1.6.1, against that statement, and test an upgrade from 1.5.0 to 1.6.0 to see if any changes affect your images. The documentation mentions a technical overview and a command reference, which are the places to look for details on the system service and networking. The tool is young, so expect to spend time on version pinning and regression testing.

Editorial conclusion

Adopt container if you are on macOS 26, work with OCI images, and want a first-party Apple tool that runs them as lightweight VMs. Do not adopt it if you are on older macOS versions, need cross-platform support, or need stronger compatibility guarantees than the README gives. Verify first that your images are OCI-compatible and that your workflows tolerate the odd breaking change the README allows for within a major release, then test the system service lifecycle with container system start and stop before integrating it into daily use.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes