Container: Apple's Linux-Container Runtime

2025-06-0920:4230544github.com

A tool for creating and running Linux containers using lightweight virtual machines on a Mac. It's written in Swift, and optimized for Apple silicon. - GitHub - apple/container: A tool for cre...

Show article

container is a tool that you can use to create and run Linux containers as lightweight virtual machines on your Mac. It's written in Swift, and optimized for Apple silicon.

The tool consumes and produces OCI-compliant container images, so you can pull and run images from any standard container registry. You can push images that you build to those registries as well, and run the images in any other OCI-compliant application.

container uses the Containerization Swift package for low level container, image, and process management.

You need an Apple silicon Mac to run container. To build it, see the BUILDING document.

container relies on the new features and enhancements present in the macOS 26 Beta 1. You can run the tool on macOS 15, but the container maintainers typically will not address issues discovered on macOS 15 that cannot be reproduced on the macOS 26 Beta 1.

There are significant networking limitations that impact the usability container on macOS 15.

If you're upgrading, first uninstall your existing container while preserving your user data:

uninstall-container.sh -k

Download the latest signed installer package for container from the GitHub release page.

To install the tool, double click the package file and follow the instructions. Enter your administrator password when prompted, to give the installer permission to place the installed files under /usr/local.

Use the uninstall-container.sh script to remove container from your system. To remove your user data along with the tool, run:

uninstall-container.sh -d

To retain your user data so that it is available should you reinstall later, run:

uninstall-container.sh -k

Contributions to container are welcomed and encouraged. Please see our main contributing guide for more information.

Read the original article

Comments

By dang 2025-06-104:09

Related ongoing threads:

Containerization is a Swift package for running Linux containers on macOS - https://news.ycombinator.com/item?id=44229348 - June 2025 (158 comments)

Apple announces Foundation Models and Containerization frameworks, etc - https://news.ycombinator.com/item?id=44226978 - June 2025 (346 comments)

(Normally we'd merge them but it seems there are significant if subtle differences between these)

By jzelinskie 2025-06-0920:431 reply

Container runs OCI (docker) compatible by creating lightweight VMs.

This repository houses the command-line interface which is powered by containerization[0], the Swift framework wrapping Virtualization.framework to implement an OCI runtime.

[0]: https://github.com/apple/containerization

By ok_computer 2025-06-0923:592 reply

I am going to show my ineptitude by admitting this, for the life of me I couldn’t get around to implement the Mac Os native way to run linux VMs and used vm-ware fusion instead. [0]

I’m glad this more accessible package is available vs docker desktop on mac os or the aforementioned, likely to be abandoned vmware non enterprise license.

[0] [apple virtualization docs](https://developer.apple.com/documentation/virtualization/cre...)

By kefirlife 2025-06-106:241 reply

Lima makes this really straightforward and supports vz virtualization. I particularly like that you can run x86 containers through rosetta2 via those Linux VMs with nerdctl. If you want to implement it yourself of course you can, but I appreciate the work from this project so far and have used it for a couple of years.

https://lima-vm.io/

By pdimitar 2025-06-1010:19

And you also have `colima`[0] on top of it that makes working with Docker on the command-line a seamless experience.

[0] https://github.com/abiosoft/colima

By mrpippy 2025-06-103:582 reply

VMware Fusion is a perfectly good way of running VMs, and IMO has a better and more native UI than any other solution (Parallels, UTM, etc)

By stephenr 2025-06-105:221 reply

This is a weird take to me.

VMWare Fusion very much feels like a cheap one-time port of VMWare Workstation to macOS. On a modern macOS it stands out very clearly with numerous elements that are reminiscent of the Aqua days: icon styles, the tabs-within-tabs structure, etc.

Fusion also has had some pretty horrific bugs related to guest networking causing indefinite hangs in the VM(s) at startup.

Parallels isn't always perfect sailing but put it this way: I have had a paid license for both (and VBox installed), for many years to build vagrant images, but when it comes to actually running a VM for purposes other than building an image, I almost exclusively turn to Parallels.

By close04 2025-06-1011:32

> reminiscent of the Aqua days

Maybe early Aqua. We're still in the Aqua days, if you don't count yesterday's Liquid Glass announcement. :)

By cpuguy83 2025-06-1013:311 reply

Not on Apple Silicon it's not. In the Intel days, sure it was great.

By mickelsen 2025-06-1622:06

I still can run the latest ARM Fedora Workstation on Apple Silicon with Fusion, and similar distros straight from the ISO without having to tweak stuff around or having problems with 3D acceleration, unlike UTM.

By 90s_dev 2025-06-102:356 reply

How actually is Swift as a Rust alternative? Is it feasible?

The only gripe I remember with it is that all its APIs are weird.

Like instead of normal names, you have Apple-legacy-names for methods/classes.

By rafram 2025-06-1011:11

Swift isn't quite as fast, because reference counting is inherently slower at runtime than the allocations/deallocations generated by the Rust borrow checker.

On the other hand, Swift has (IMO) a much cleaner and less symbol-heavy syntax than Rust. Easier to read and write. Less of a culture of doing crazy metaprogramming/DSL definition with macros, and the builder DSL built into the language (which SwiftUI uses) is pretty nice and generates mostly understandable compile errors.

I actually like Apple's APIs, even the legacy ones. There's some weirdness, like how some file APIs want paths and some want URIs, but it's not that bad.

By written-beyond 2025-06-105:03

Rust and Swift have done a fair bit of borrowing from each other "pun intended".

I've never got the chance to work with swift since their cross platform compatibility and "server-side swift" have been recent introductions.

In terms comparison, it really is the closest you can get to a rust that ARC BOX's everything (which has/ is planned to come down when lifetimes come in). You get a good runtime and good performance.

By tcmart14 2025-06-104:39

I can't speak to performance since I don't really race languages. But as far as feel and what not, it is very similar. But there is also a pretty good overlap in people who worked on Rust and people who worked in Swift. Graydon worked on both. So Swift has a lot of similarities with Rust. The way I usually word it is, Swift is like having C# with mostly everything you like about Rust.

I believe a lot of the legacy names come from when your interfacing with platform APIs like UIKit and such if you have to and they haven't quiet gotten a bump from their Objective-C APIs to have more swifty-APIs.

By EPWN3D 2025-06-102:411 reply

Depends on what you're doing. If you want to write systems code, Swift is very allocation-happy and will probably not be the best fit. They're trying to make an embedded Swift, but progress is pretty slow, since that's not going to be something that gets anyone promoted.

If you just want to write A Thing, then it's up to your individual taste, what's available in the ecosystem, etc.

By dwaite 2025-06-1022:43

Apple has started using Swift for production embedded code run within the Secure Enclave. I've been looking out for any evidence whether they are using it in the C1 modem baseband.

I don't think I'd push for it over Rust for those applications, but there is apparently wood behind the arrow internally.

By dwaite 2025-06-1022:40

They are different language designs sharing quite a few of the same features/philosophies.

Swift is good for business logic, like writing an app.

Rust is better for infrastructure, like writing a HTTP/3 server or Javascript VM.

Swift has an extremely good story about ABI stability, which makes sense when Apple ships a swift runtime and libraries as part of the OS, and needs the binaries to work across two dozen different major/minor releases.

Rust has up-front memory control primitives and options to remove the core library to cater to things like embedded systems development.

People have written apps in Rust, and Apple has written API backends and even device firmwares in Swift. I would argue both push against the ergonomics of the respective languages.

By waterTanuki 2025-06-105:56

much of the new swift libraries/apis don't have the legacy "NS" prefixes you're thinking of

Hacker News