The CLI from the press release/WWDC session is at https://github.com/apple/container which I think is what many like myself would be interested in. I was hoping this'd be shipped with the newest Xcode Beta but that doesn't seem to be the case. Prebuilt packages are missing at the moment but they are working on it: https://github.com/apple/container/issues/54
This is the most surprising and interesting part, imo:
> Contributions to `container` are welcomed and encouraged. Please see our main contributing guide for more information.
This is quite unusual for Apple, isn't it? WebKit was basically a hostile fork of KHTML, Darwin has been basically been something they throw parts of over the wall every now and then, etc.
I hope this and other projects Apple has recently put up on GitHub see fruitful collaboration from user-developers.
I'm a F/OSS guy at heart who has reluctantly become a daily Mac user due to corporate constraints that preclude Linux. Over the past couple of years, Apple Silicon has convinced me to use an Apple computer as my main laptop at home (nowadays more comparable, Linux-friendly alternatives seem closer now than when I got my personal MacBook, and I'm still excited for them). This kind of thing seems like a positive change that lets me feel less conflicted.
Anyway, success here could perhaps be part of a virtuous cycle of increasing community collaboration in the way Apple engages with open-source. I imagine a lot of developers, like me, would both personally benefit from this and respect Apple for it.
Chromiom is a hostile fork of WebKit. Webkit was a rather polite fork of KHTML, just that they had a team of full time programmers so KHTML couldn't keep up with the upstream requests and gave up since WebKit did a better job anyway.
I personally would LOVE if a corporation did this to any of my open source projects.
I find Apple to be very collaborative on OSS - I hacked up a feature I needed in swift-protobuf and over a couple of weeks two Apple engineers and one Google engineer spent a significant amount of time reviewing and helping me out. It was a good result and a great learning experience.
I too am more of a reluctant convert to Mac from Linux. It really does just work most of the time for me in the work context. It allows me to get my job done and not worry because it’s the most supported platform at the office. Shrug. But also the hardware is really really really nice.
I do have a personal MacBook pro that I maxed out (https://gigatexal.blog/pages/new-laptop/new-laptop.html) but I do miss tinkering with my i3 setup and trying out new distos etc. I might get a used thinkpad just for this.
But yeah my Mac personal or work laptop just works and as I get older that’s what I care about more.
Going to try out this container binary from them. Looks interesting.
At first I thought this sounded like a blend of the virtualisation framework with a firecracker style lightweight kernel.
This project had its own kernel, but it also seems to be able to use the firecracker one. I wonder what the advantages are. Even smaller? Making use of some apple silicon properties?
Has anyone tried it already and is it fast? Compared to podman on Linux or Docker Desktop for Mac?
The advantage is, now there's an Apple team working on it. They will be bothered by their own bugs and hopefully get them fixed.
Virtualization.framework and co was buggy af when introduced and even after a few major macOS versions there are still lots of annoyances, for example the one documented in "Limitations on macOS 15" of this project, or half-assed memory ballooning support.
Hypervisor.framework on the other hand, is mostly okay, but then you need to write a lot more codes. Hypervisor.framework is equivalent to KVM and Virtualization.framework is equivalent to qemu.
Really curious how this improves the filesystem bridging situation (which with Docker Desktop was basically bouncing from "bad" to "worse" and back over the years). Or whether it changes it at all.
Has anyone tried turning on nested virt yet? Since the new container CLI spins each container in its own lightweight Linux VM via Virtualization.framework, I’m wondering whether the framework will pass the virtualization extensions through so we can modprobe kvm inside the guest.
Apple’s docs say nested virtualization is only available on M3-class Macs and newer (VZGenericPlatformConfiguration.isNestedVirtualizationSupported)
developer.apple.com, but I don’t see an obvious flag in the container tooling to enable it. Would love to hear if anyone’s managed to get KVM (or even qemu-kvm) running inside one of these VMs.
Needing two of the most famous non-Linux operating systems for the layman to sanely develop programs for Linux systems is not particularly a victory if you look at it from that perspective. Just highlights the piss-poor state of Linux desktop even after all these years. For the average person, it's still terrible on every front and something I still have a hard time recommending when things so often go belly up.
Before you jump on me, every year, I install the latest Fedora/Ubuntu (supposedly the noob-friendly recommendations) on a relatively modern PC/Laptop and not once have I stopped and thought "huh, this is actually pretty usable and stable".
On the server room yes, but only in the sense UNIX has won, and Linux is the cheapest way to acquire UNIX, with the BSDs sadly looking from their little corner.
However on embedded, and desktop, the market belongs to others, like Zehyr, NutXX, Arduino, VxWorks, INTEGRITY,... and naturally Apple, Google and Microsoft offerings.
Also Linux is an implementation detail on serverless/lambda deployments, only relevant to infrastructure teams.
Well. It can also be argued that the other two platforms are finding ways to allow using Linux without leaving those platforms, which slows down market share of Linux on desktop as the primary OS.
That isn’t exactly new, the hypervisor underneath has been in macOS for years, but poorly exploited. It’s gained a few features but what’s really substantial today are the (much) enhanced ergonomics on top.
Fascinating to me how Windows and Linux have cross-pollinated each other through things like WSL and Proton. Platform convergence might become a thing within our lifetimes.
Linux has already won, in the form of Android and to an extent ChromeOS. Many people just don't recognize it as such because most of the system isn't the X11/Wayland desktop stack the "normal" Linux distros use.
Hell, Samsung is delivering Linux to the masses in the form of Wayland + PulseAudio under the brand name "Tizen". Unlike desktop land, Tizen has been all-in on Wayland since 2013 and it's been doing fine.
"It" (aka the cloud providers) has won in the foobar POSIX department such that only a full Linux VM can run your idiosyncractic web apps despite or actually because of hundreds of package managers and dependency resolution and late binding mechanisms, yes.
I need to look into this a little more, but can anyone tell me if this could be used to bundle a Linux container into a MacOS app? I can think of a couple of places that might be useful, for example giving a GPT access to a Linux environment without it having access to run root CLI commands.
Thinking more about this a bit, one immediate issue I see with adoption is that the idea of launching each container in its own VM to fully isolate it and give it its own IP, while neat, doesn't really translate to Linux or Windows. This means if you have a team of developers and a single one of them doesn't have a mac, your local dev model is already broken. So I can't see a way to easily replace Docker/Compose with this.
It translates exactly to Kubernetes though, except without the concept of pods, I don't see anything in this that would stop them adding pods on top later, which would allow Kubernetes or compose like setups (multiple containers in the same pod).
I wonder if this will dramatically improve gaming on a Mac? Valve has been making games more reliable due to Steam Deck, and gaming on Linux is getting better every year.
Could games be run inside a virtual Linux environment, rather than Apple’s Metal or similar tool?
This would also help game developers - now they only need to build for Windows, Linux, and consoles.
Huh. I suppose it’s a good thing I never came around to migrating our team from docker desktop to Orbstack, even though it seems like they pioneered a lot of the Apple implementation perks…
They could replace their underlying implementations with this, and for most users, they wouldn't notice the difference, other than any performance gains.
that's nice and all - but where are the native Darwin containers? Why is it ok for Apple to continue squeezing people with macOS CI jobs to keep buying stupid Mac Minis to put in racks only to avoid a mess? Just pull FreeBSD jails!
I would really want to have a macOS (not just Darwin) container, but it seems that it is not possible with macOS. I don't remember the specifics, but there was a discussion here at HN a couple of month ago and someone with intrinsic Darwin knowledge explained why.
Forget Linux containers on Mac, as far as I’m concerned that’s already a solved problem. What about Mac containers? We still don’t have a way to run a macOS app with its own process namespace/filesystem in 2025. And with all this AI stuff, there’s a need to minimise blast radius of a rogue app more than ever.
Is there any demand for mac binaries in production? I can't think of a single major cloud provider that offers Mac hardware based k8s nor why you'd want to pay the premium over commodity hardware. Linux seems to be the lingua franca of containerized software distribution. Even windows support for containers is sketchy at best
Looks cool! In the short demo [0] they mention "within a few hundred milliseconds" as VM boot time (I assume?). I wonder how much tweaking they had to do, because this is using the Virtualization.framework, which has been around a while and used by Docker dekstop / Colima / UTM (as an option).
I wonder what the memory overhead is, especially if running multiple containers - as that would spin up multiple VM's.
[+] [-] commandersaki|9 months ago|reply
Looks like each container gets its own lightweight Linux VM.
Can take it for a spin by downloading the container tool from here: https://github.com/apple/container/releases (needs macOS 26)
[+] [-] sangeeth96|9 months ago|reply
[+] [-] candiddevmike|9 months ago|reply
[+] [-] pxc|9 months ago|reply
> Contributions to `container` are welcomed and encouraged. Please see our main contributing guide for more information.
This is quite unusual for Apple, isn't it? WebKit was basically a hostile fork of KHTML, Darwin has been basically been something they throw parts of over the wall every now and then, etc.
I hope this and other projects Apple has recently put up on GitHub see fruitful collaboration from user-developers.
I'm a F/OSS guy at heart who has reluctantly become a daily Mac user due to corporate constraints that preclude Linux. Over the past couple of years, Apple Silicon has convinced me to use an Apple computer as my main laptop at home (nowadays more comparable, Linux-friendly alternatives seem closer now than when I got my personal MacBook, and I'm still excited for them). This kind of thing seems like a positive change that lets me feel less conflicted.
Anyway, success here could perhaps be part of a virtuous cycle of increasing community collaboration in the way Apple engages with open-source. I imagine a lot of developers, like me, would both personally benefit from this and respect Apple for it.
[+] [-] boxed|9 months ago|reply
Chromiom is a hostile fork of WebKit. Webkit was a rather polite fork of KHTML, just that they had a team of full time programmers so KHTML couldn't keep up with the upstream requests and gave up since WebKit did a better job anyway.
I personally would LOVE if a corporation did this to any of my open source projects.
[+] [-] holycrapwhodat|9 months ago|reply
WebKit has been a fully proper open source project - with open bug tracker, patch review, commit history, etc - since 2005.
Swift has been a similarly open project since 2015.
Timeline-wise, a new high profile open source effort in 2025 checks out.
[+] [-] willtemperley|9 months ago|reply
[+] [-] gigatexal|9 months ago|reply
I do have a personal MacBook pro that I maxed out (https://gigatexal.blog/pages/new-laptop/new-laptop.html) but I do miss tinkering with my i3 setup and trying out new distos etc. I might get a used thinkpad just for this.
But yeah my Mac personal or work laptop just works and as I get older that’s what I care about more.
Going to try out this container binary from them. Looks interesting.
[+] [-] zapzupnz|9 months ago|reply
[+] [-] noufalibrahim|9 months ago|reply
[+] [-] overfeed|9 months ago|reply
I suspect this move was designed to stop losing people like you to WSL.
[+] [-] unknown|9 months ago|reply
[deleted]
[+] [-] nhumrich|9 months ago|reply
[+] [-] spockz|9 months ago|reply
This project had its own kernel, but it also seems to be able to use the firecracker one. I wonder what the advantages are. Even smaller? Making use of some apple silicon properties?
Has anyone tried it already and is it fast? Compared to podman on Linux or Docker Desktop for Mac?
[+] [-] rfoo|9 months ago|reply
Virtualization.framework and co was buggy af when introduced and even after a few major macOS versions there are still lots of annoyances, for example the one documented in "Limitations on macOS 15" of this project, or half-assed memory ballooning support.
Hypervisor.framework on the other hand, is mostly okay, but then you need to write a lot more codes. Hypervisor.framework is equivalent to KVM and Virtualization.framework is equivalent to qemu.
[+] [-] julik|9 months ago|reply
[+] [-] sitole|9 months ago|reply
Apple’s docs say nested virtualization is only available on M3-class Macs and newer (VZGenericPlatformConfiguration.isNestedVirtualizationSupported) developer.apple.com, but I don’t see an obvious flag in the container tooling to enable it. Would love to hear if anyone’s managed to get KVM (or even qemu-kvm) running inside one of these VMs.
[+] [-] sho_hn|9 months ago|reply
You can make some kind of argument from this that Linux has won; certainly the Linux syscall API is now perhaps the most ubiquitous application API.
[+] [-] sangeeth96|9 months ago|reply
Needing two of the most famous non-Linux operating systems for the layman to sanely develop programs for Linux systems is not particularly a victory if you look at it from that perspective. Just highlights the piss-poor state of Linux desktop even after all these years. For the average person, it's still terrible on every front and something I still have a hard time recommending when things so often go belly up.
Before you jump on me, every year, I install the latest Fedora/Ubuntu (supposedly the noob-friendly recommendations) on a relatively modern PC/Laptop and not once have I stopped and thought "huh, this is actually pretty usable and stable".
[+] [-] pjmlp|9 months ago|reply
However on embedded, and desktop, the market belongs to others, like Zehyr, NutXX, Arduino, VxWorks, INTEGRITY,... and naturally Apple, Google and Microsoft offerings.
Also Linux is an implementation detail on serverless/lambda deployments, only relevant to infrastructure teams.
[+] [-] aljgz|9 months ago|reply
[+] [-] inopinatus|9 months ago|reply
[+] [-] flmontpetit|9 months ago|reply
[+] [-] jeroenhd|9 months ago|reply
Hell, Samsung is delivering Linux to the masses in the form of Wayland + PulseAudio under the brand name "Tizen". Unlike desktop land, Tizen has been all-in on Wayland since 2013 and it's been doing fine.
[+] [-] tannhaeuser|9 months ago|reply
[+] [-] duped|9 months ago|reply
[+] [-] paxys|9 months ago|reply
Brag about this to an average Windows or Mac user and they will go "huh?" and "what is Linux?"
[+] [-] OJFord|9 months ago|reply
[+] [-] roberttod|9 months ago|reply
[+] [-] paxys|9 months ago|reply
[+] [-] dontdoxxme|9 months ago|reply
[+] [-] SamuelAdams|9 months ago|reply
Could games be run inside a virtual Linux environment, rather than Apple’s Metal or similar tool?
This would also help game developers - now they only need to build for Windows, Linux, and consoles.
[+] [-] solomatov|9 months ago|reply
[+] [-] jbverschoor|9 months ago|reply
They have Xcode cloud.
The $4B contract with Amazon ends, and it’s highly profitable.
Build a container, deploy on Apple, perhaps with access to their CPU’s
[+] [-] newman314|9 months ago|reply
[+] [-] SparkyMcUnicorn|9 months ago|reply
People still want the nice UI/UX, and this is just a Swift package.
[+] [-] 9dev|9 months ago|reply
[+] [-] bdcravens|9 months ago|reply
[+] [-] pmarreck|9 months ago|reply
[+] [-] qalmakka|9 months ago|reply
[+] [-] conradludgate|9 months ago|reply
[+] [-] egorfine|9 months ago|reply
I would really want to have a macOS (not just Darwin) container, but it seems that it is not possible with macOS. I don't remember the specifics, but there was a discussion here at HN a couple of month ago and someone with intrinsic Darwin knowledge explained why.
[+] [-] outcoldman|9 months ago|reply
[+] [-] cedws|9 months ago|reply
[+] [-] hadlock|9 months ago|reply
[+] [-] tgma|9 months ago|reply
[+] [-] rfoo|9 months ago|reply
[+] [-] worldsavior|9 months ago|reply
[+] [-] unknown|9 months ago|reply
[deleted]
[+] [-] filleokus|9 months ago|reply
I wonder what the memory overhead is, especially if running multiple containers - as that would spin up multiple VM's.
[0]: https://developer.apple.com/videos/play/wwdc2025/346 10:10 and forwards