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.
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.
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.
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.
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.
Microsoft did it too with Windows and Words (supposedly after a very messy trademark dispute around excel? If I remember well?). This avoids trademark dispute on names (as you can’t trademark generic name alone) and is an effective way for very recognizable brands to extend their branding without adding too much confusion
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).
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.
Related ongoing threads:
Containerization is a Swift package for running Linux containers on macOS - 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/
1 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)
3 replies →
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.
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.
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.
much of the new swift libraries/apis don't have the legacy "NS" prefixes you're thinking of
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.
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 was wondering the same thing
Apple has a track record of doing that: product names that are only unique if you keep repeating the "Apple" prefix.
Apple Card
Apple Pay
Apple Music
Apple TV
Apple Watch
App Store (trying to namesquat this is just evil, so it's "Apple App Store" for me)
Hence, I recommend you call it "Apple Container", and "Apple Containerization".
Microsoft did it too with Windows and Words (supposedly after a very messy trademark dispute around excel? If I remember well?). This avoids trademark dispute on names (as you can’t trademark generic name alone) and is an effective way for very recognizable brands to extend their branding without adding too much confusion
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.
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.
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!
2 replies →
Oh, like OP I didn’t see the difference. I believe the difference is:
Container is a CLI tool
Containerization is a framework
1 reply →
Does this enable running containers next apps to iOS and MacOS downloaded from AppStore?
I just need this to get a GUI and it will be close to perfect.
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.
2 replies →
Not for iPadOS, alas.
well of course, the ipad is not a computer (despite what the marketing says)