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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
You're right, it's an incredibly pyrrhic decisions that aims to wrestle the meaning of the word towards apple's implementation. I mean, the company is named "apple". This kind of raze-a-language marketing is in their DNA.
I disagree, they are different, and that (containerization, not container here) is the more novel/interesting one imo. It'd be nice to focus the discussion more (though at present there are many confused comments there that think they're discussing the container tool).
On the contrary, it was helpful. Normally "containerization framework" and "container runtime" announced on the same day by the same company would obviously be the same story—but this was a rare exception and I'm glad you pointed it out!
Yes, container is like `docker` CLI: 'I am a developer and I want to run a container'; containerization is for packaging OCI image container sidecars into Swift .apps - you could distribute your app with postgres 'built in' (but running as a container), user doesn't need to ensure it's installed and running separately or anything.
Cross posting in the right place instead of the other thread:
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?
Care to elaborate why exactly this is such a bad implementation of containers?
Seems like a more secure implementation than Docker Engine, and if - as I pressure - memory management is automatic, then it will be pretty great to use.
> and if - as I pressure [presume?] - memory management is automatic
Why would it be? Nothing in the Linux kernel properly supports that on a VM level (ballooning only goes in one direction, and even that only on a good day), and if Apple had managed to solve that particular Gordian knot they would've told people.
I've yet to see it actually work reliably, but YMMV. Either way there doesn't seem to be any indication of a similar feature attempt for Apple's runtime - since containers are meant to be restarted regularly, they might just not bother with wasting time on that feature.
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)
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
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...)
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/
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
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)
Not on Apple Silicon it's not. In the Intel days, sure it was great.
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.
> 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. :)
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.
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.
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.
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.
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.
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.
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.
much of the new swift libraries/apis don't have the legacy "NS" prefixes you're thinking of
I have been using lima to run Linux VMs on macOS. This new Apple tool looks very similar and I might replace lima with it.
Is it smart to call the implementation after the category, or am I misunderstanding what is going on? Surely they won't be able to trademark this?
It's not a product; it's a command line tool that's (more or less) part of the OS. It doesn't need a fancy name.
I was wondering the same thing
You're right, it's an incredibly pyrrhic decisions that aims to wrestle the meaning of the word towards apple's implementation. I mean, the company is named "apple". This kind of raze-a-language marketing is in their DNA.
Will it be possible to integrate this with docker, so docker containers on Mac run more performance optimized?
According to jzelinskie, yes: https://news.ycombinator.com/item?id=44229248
This is a layer on top of the operating system support for virtualization, which Docker Desktop (and tons of open source alternatives) already use.
I just need this to get a GUI and it will be close to perfect.
Should probably merge with https://news.ycombinator.com/item?id=44229348
I disagree, they are different, and that (containerization, not container here) is the more novel/interesting one imo. It'd be nice to focus the discussion more (though at present there are many confused comments there that think they're discussing the container tool).
Whoops, I merged them but you've persuaded me to unmerge them. This will take a bit of time.
Edit: reverted!
Oh no, sorry! :)
On the contrary, it was helpful. Normally "containerization framework" and "container runtime" announced on the same day by the same company would obviously be the same story—but this was a rare exception and I'm glad you pointed it out!
Oh, like OP I didn’t see the difference. I believe the difference is:
Container is a CLI tool
Containerization is a framework
Yes, container is like `docker` CLI: 'I am a developer and I want to run a container'; containerization is for packaging OCI image container sidecars into Swift .apps - you could distribute your app with postgres 'built in' (but running as a container), user doesn't need to ensure it's installed and running separately or anything.
Does this enable running containers next apps to iOS and MacOS downloaded from AppStore?
Cross posting in the right place instead of the other thread:
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?
[flagged]
This comment doesn’t seem very substantive.
Care to elaborate why exactly this is such a bad implementation of containers?
Seems like a more secure implementation than Docker Engine, and if - as I pressure - memory management is automatic, then it will be pretty great to use.
> and if - as I pressure [presume?] - memory management is automatic
Why would it be? Nothing in the Linux kernel properly supports that on a VM level (ballooning only goes in one direction, and even that only on a good day), and if Apple had managed to solve that particular Gordian knot they would've told people.
Isn’t memory management somewhat automatic on WSL2? Isn’t that the same problem?
I've yet to see it actually work reliably, but YMMV. Either way there doesn't seem to be any indication of a similar feature attempt for Apple's runtime - since containers are meant to be restarted regularly, they might just not bother with wasting time on that feature.
Not for iPadOS, alas.
well of course, the ipad is not a computer (despite what the marketing says)