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 macOS 15 or 16, 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. This is not a daemon that auto-starts on login. 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 that is still pre-1.0. 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. It says stability is only guaranteed within patch versions, such as between 0.1.1 and 0.1.2. Minor version releases may include breaking changes until a 1.0.0 release. The current releases are 1.3.1, 1.3.0, and 1.2.2, which means the project is past 1.0.0, but the README text still says 'until we reach a 1.0.0 release.' That is an inconsistency. The repository shows releases labeled 1.x, but the project status text has not been updated. This is a real red flag: either the README is stale, or the versioning scheme changed. In either case, you should not assume that minor version bumps are safe. The documented guarantee applies only to patch versions. For a tool that runs as a system service, that is a meaningful operational risk. You may need to 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 the majority of Macs in the field, which are likely on macOS 15 or 16. 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 warns that stability is only guaranteed within patch versions. Before adopting, verify that the current release, 1.3.1, actually matches the README's stability statement. Check whether the project has updated its status text, and test an upgrade from 1.2.2 to 1.3.0 to see if any breaking 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 require stability across minor releases before 1.0.0. Verify first that your images are OCI-compatible and that your workflows tolerate breaking changes between minor versions, then test the system service lifecycle with container system start and stop before integrating it into daily use.

Official sources

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