People still want the nice UI/UX, and this is just a Swift package.
License aside, though, I would still bet that relying on the Apple-specific version of something like this will cause headaches for teams unless you're operating in an environment that's all-in on Apple. Like, your CI tooling in the cloud runs on a Mac, that degree of vendor loyalty. I've never seen any shop like that.
Plus when this tooling does have interoperability bugs, I do not trust Apple to prioritize or even notice the needs of people like me, and they're the ones in charge of the releases.
Presumably it's not as good right now but where it ends up depends entirely on Apple's motivation. When they are determined they can build very good things.
Docker for Mac builds it in 4 minutes.
container tool... 17 minutes. Maybe even more. And I did set the cpu and memory for the builder as well to higher number than defaults (similar what Docker for Mac is set for). And in reality it is not the build stage, but "=> exporting to oci image format" that takes forever.
Running containers - have not seen any issues yet.
Do people learn docker not via the CLI?
And like I'm not all anti-GUI, it's just that docker is one of those things I've never even imagined using a GUI for
For Kubernetes, something like K9s [1] or Headlamp [2] works fine. I remember seeing something similar for Docker but I can't remember the name.
The nice part is that they (a) set up the Linux VM that runs the Docker daemon for you and (b) handle the socket forwarding magic that lets you communicate with it "directly" by running the Docker client on the host OS. This is likewise true for Podman Desktop, Rancher Desktop, etc.
The GUI is icing on the cake, imo.
I'll not deny that it's a bit niche, but not so much so that it's completely unknown.
"Apple developer circles" to me means the few mostly indies who build non-electron Mac apps and non-ReactNative ios apps, but those developers mostly are writing client code and don't even touch servers.
All this said, my above "gut feelings" don't explain why Apple would have bothered spending their time making this when Orbstack, Docker, etc. already meet the needs of the developers on Mac who actually need and use containers.
[0]: besides the "Command line tools" that allow compilation to work, of course.
My org's management wasn't taking the issue seriously, but once the subscription cost reached one FTE's salary, they started listening to people who had already switched to Podman, Rancher or (Co)Lima.
If it doesn't, then it's still a toss-up whether or not user chooses docker/podman/this...etc.
If it ends up shipping by default and is largely compatible with the same command line flags and socket API... Then docker has a problem.
For what it's worth, I prefer podman but even on Linux where the differentiators should be close to zero, I still find certain things that only docker does.
Docker for Desktop sits on-top of container/virtualization software (Hypervisor.framework and QEMU on Mac, WSL on Windows, containerd on Linux). So there's a good chance that future versions of Docker for Desktop will use this library, but they don't really compete with each other.
I'm not sure this is the same, though. This feels more like docker for desktop running on a lightweight vm like Colima. Am I wrong?
OCI containers are supposed to be "one container, one PID": at the very least the container's server is PID1 (at times other processes may be spawned but typically the container's main process is going to be PID1).
Containerization is literally the antithesis of systemd.
So I don't understand your comment.
It isn't systemd:
> Containers achieve sub-second start times using an optimized Linux kernel config, minroot filesystem, and a lightweight init system, vminitd
This guide seems to have no specific license agreement.
https://www.freecodecamp.org/news/install-xcode-command-line...
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
> Containers achieve sub-second start times using an optimized Linux kernel configuration[0] and a minimal root filesystem with a lightweight init system.
[0]: https://github.com/apple/containerization/blob/main/kernel/c...
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
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)
The former is for apps to ship with container sidecars (and cooler news IMO); the latter is 'I am a developer and I want to `docker run ...`'.
(Oh, and container has a submission here: https://news.ycombinator.com/item?id=44229239)
Let's run linux inside a container inside docker inside macos inside an ec2 macos instance inside a aws internal linux host inside a windows pc inside the dreaming mind of a child.
And inside that linux maybe run qemu with munal os [https://github.com/Askannz/munal-os]
Not even the first non-hyperbolic part of what you wrote is correct. "Container" most often refers to OS-level virtualization on Linux hosts using a combination of cgroups, resource groups, SDN, and some mount magic (among other things). MacOS is BSD-based and therefore doesn't support the first two things in that list. Apple can either write a compatibility shim that emulates this functionality or virtualize the Linux kernel to support it. They chose the latter. There is no Docker involved.
This is a completely sane and smart thing for them to do. Given the choice I'd still much rather run Linux but this brings macOS a step closer to parity with such.
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.
Brag about this to an average Windows or Mac user and they will go "huh?" and "what is Linux?"
Depending on what you mean with "the game", I'd say even more so.
MS/Apple used to villify or ridicule Linux, now they need to distribute it to make their own product whole, because it turns out having an Open Source general purpose OS is so convenient and useful it's been utilized in lots of interesting ways - containers, for example - that the proprietary OS implementations simply weren't available for. I'd say it's a remarkable development.
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".
The desktop marketshare stats back me up on the earlier point and last I checked, no distro got anywhere close?
Sure, Android is the exception (if we agree to consider) but until we get serious dev going there and until Android morphs into a full-fledged desktop OS, my point stands.
I think what slows down market share of Linux on desktop is Linux on desktop itself.
I use Linux, and I understand that it's a very hard job to take it to the level of Windows or macOS, but it is what it is.
> 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.
If my biases are already outdated, I'm happy to learn that. Either way, my hopes are the same. :)
Besides, I think OP wasn't talking about licenses; Apple has a lot of software under FOSS licenses. But usually, with their open-source projects, they reject most incoming contributions and don't really foster a community for them.
They don't have to do literally any of this.
I suspect this move was designed to stop losing people like you to WSL.
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.
rvz•4h ago
> You need an Apple silicon Mac to build and run Containerization.
> To build the Containerization package, your system needs either:
> macOS 15 or newer and Xcode 26 Beta
> macOS 26 Beta 1 or newer
Those on Intel Macs, this is your last chance to switch to Apple Silicon, (Sequoia was the second last)[0] as macOS Tahoe is the last version to support Intel Macs.
[0] https://news.ycombinator.com/item?id=41560423
keysdev•4h ago
bjackman•4h ago
https://askubuntu.com/questions/55868/installing-broadcom-wi...
Not sure about the newer ones.
Gathering this information and putting together a distro to rescue old Macbooks from the e-waste bin would be a worthwhile project. As far as I can tell they're great hardware.
I imagine things get harder once you get into the USB-C era.
monkey_monkey•3h ago
https://t2linux.org/
haiku2077•4h ago
socalgal2•3h ago
DrBenCarson•3h ago
nicoburns•3h ago
paxys•3h ago
xp84•2h ago
I like the hardware, hate the absurd greedy storage and RAM prices.
paxys•1h ago
xp84•1h ago
xp84•2h ago
pjmlp•3h ago