Why should I use Apple's `container`?

Server Docker
1

I've watched the WWDC 2025 Meet Containerization session and the Swift for Low-Level Container infrastructure talk in last year's Swift-Server conference, but I have yet to have a good idea about some concrete advantages of Apple's container compared to docker / podman.

I'm sure there are some advantages, I just don't know what they are.

The talks are great, but they include a lot of vague comparisons which don't help in drawing the accurate conclusions that I'm looking for.
For example the talks use a lot of language similar to "historically it was that but we did this". While this gives some ideas about differences/advantages of container over the most common competing tool which is docker, it doesn't sound like it wants to commit to the statement, which makes me uncomfortable about relying on it.

Another reason for the fact that those kinds of statements don't help a lot is that while I have a good understanding of Unix / Linux / containers, I don't have a deep understanding of how the actual tools like docker behave, so I can compare it to what the talks mention and be like "I know docker does this another way, so it's nice to see container taking the better route", so it's also partially on me.

Anyway, I'm not trying to complain about the talks. Again, they were great.

What I'm trying to do is to ask for some concrete comparisons.
Perhaps a table with docker / podman / container as columns and some of their major differences as rows would be a very clear and helpful way of doing such a comparison and could even end up in some documentation or such.
I wouldn't mind some performance benchmarks either.
I'd also appreciate any other kinds of information.

I also don't mind if container has some missing functionalities, which would be normal for a new tool. This is more about knowing what is different about container in what it already does.

For context, I have yet to try container although I use containers on the daily. I usually do try the new stuff early on, but I have yet to feel inclined to do so with container.

5 Likes
2

Good question,

I think one reason could be another kind of isolation. You use tiny VM there don’t share the same Kernel.

This leads to better resource efficiency. If there is no container running you don’t have any overhead.

But it’s still a young framework, I hope we get native docker-compose.yml support this WWDC.

3 Likes
3

Architecturally, for podman it appears that it uses one VM for all containers whereas the containerization framework uses one VM per container, as far as I understand. The latter is also Swift-native, which presumably means the build process is more straightforward and familiar on macOS, as opposed to podman which requires a Go toolchain and brew.

1 Like
4

Thank you, those are valuable info.

I think there are likely a lot more (high-level) differences as well, considering container comes with its own init implementation (vminitd), for one.

5

This is not so much a differentiator as it is a consequence of having to use a virtual machine.

6

Not completely the same question… but if I currently use the swiftly tool to install toolchains on Linux boxes for CI jobs do I have any compelling reason to migrate that CI job to use the Apple Container? Or is that all kind of overthinking things for what I am trying to do if all I need is to build and test a repo?

7

I ... don't believe container can help much here, assuming a somewhat-typical setup.

container is macOS-only although it can produce Linux containers. If your CI runs on Linux then you can't use container itself there.
Even if the CI uses macOS, I still wouldn't recommend using containers, as you'll be running your jobs on Linux if you use containers even on macOS.
Containers are an entirely Linux-related concept, the only way you can run a container on macOS is to first run a Linux VM to host the container.

See Vapor's CI setup. There are macOS, Linux, Android, and some more CI jobs defined there.

1 Like