WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Meet Containerization

Meet Containerization

Developer Tools
Watch original video

Highlight

Containerization is an open-source Swift framework from Apple. Each Linux container runs in its own lightweight VM, starts in sub-seconds, gets a dedicated IP, and has zero resource overhead when no container is running.

Core Content

Running Linux containers on Mac used to have one mainstream path: launch a big VM, stuff all containers inside, and share everything. Resources get allocated internally, directories must be mounted to the VM first then passed through to containers, ports need mapping, and the attack surface expands with the big VM. Developers get a Linux environment, but security and isolation both take a hit.

At WWDC 25, Apple offered another direction: Containerization. This is an open-source framework written in Swift that provides image management, container execution, and a Swift-based init system. The key trade-off: each container runs in its own lightweight VM, starting in sub-seconds. Each container gets a dedicated IP, no port mapping needed; directories are shared at container granularity, only the requesting container sees the content; when no container is running, resource overhead is zero. Above the framework sits an open-source CLI tool container that gets you into an Alpine container shell in a few hundred milliseconds (11:03).

Details

Image management (04:10). An image is a distribution artifact containing filesystem content plus default configuration, serving as a template for new containers. Containerization provides APIs to pull from the Registry and write the response locally. The image filesystem is not unpacked file by file; instead, it’s formatted as a block device: create a large file, then format it with EXT4. EXT4 is a filesystem widely used in Linux, and the framework provides a Swift package that can format, create directory structures, and populate EXT4 content directly from Swift (05:41).

Inside the VM, vminitd takes over (07:14). It’s a Swift-based init system that runs as the VM’s first process, responsible for assigning IPs to network interfaces, mounting the filesystem exposed by the image block device, starting and supervising all processes within the VM, and exposing APIs to the host for launching processes remotely. The minimal filesystem provided by Containerization has no libc, no dynamic libraries, and no core utilities like cd/cp/ls (08:22). To run in this environment, vminitd is cross-compiled using the Swift Static Linux SDK into a static executable, linked against musl, a libc implementation with good static linking support (08:43).

The container CLI assembles these pieces into a developer-friendly interface (09:26). It consists of a CLI and several XPC services, handling Storage, image management, Network (IP allocation and DNS), and the container runtime respectively. Pull an image:

container image pull alpine:latest

Key points:

  • container is an open-source CLI tool built on the Containerization framework
  • image pull subcommand requests the latest Alpine filesystem and configuration from the Registry
  • The pull process creates a block file locally containing the EXT4-formatted image content

Run an interactive shell (10:43):

container run -t -i alpine:latest sh

Key points:

  • run creates a container using the image’s filesystem and configuration, then launches a lightweight VM through the framework
  • -t requests a TTY terminal device, -i connects current input to the container, together yielding an interactive shell
  • The last two segments are the image name and command to execute; here we directly run sh
  • In the demo, the container enters shell within a few hundred milliseconds, uname -a shows a Linux environment, ps aux only sees its own shell and ps processes, host and other container processes are invisible (11:08)

The security benefits of this design come from two factors working together: each container’s isolation boundary equals that of a complete VM; inside the VM, lacking core utilities and dynamic libraries, attackers have few tools available after landing.

Key Takeaways

  • Replace Docker Desktop with container CLI for local development first: Why do it—eliminate the resource overhead of a constantly-running big VM, no memory used when no containers are running; dedicated IPs mean multi-service debugging no longer requires writing piles of port mappings. How to start—container image pull to fetch common base images, run your team’s Dockerfiles locally with container run, verify consistent behavior.
  • Produce zero-dependency Linux binaries with Swift Static Linux SDK: Why do it—vminitd proves Swift can cross-compile static Linux executables with no libc dependency, deploy to any minimal image without worrying about dynamic library issues. How to start—set up Static Linux SDK on Mac, pick a small tool originally written in Go/Rust, rewrite it in Swift, link against musl, verify size and startup speed.
  • Use the EXT4 Swift package in image/disk toolchains: Why do it—previously building Linux filesystems from macOS required e2fsprogs or Docker; now you can do formatting, directory creation, and content population purely in Swift. How to start—reference the EXT4 package from the Containerization repo, write a CLI that packages a local directory into an EXT4 block file, use it as a VM’s root disk.
  • Refactor local multi-service debugging with per-container dedicated IPs: Why do it—dedicated IPs bring production’s service-to-service calling pattern directly to local development, dropping the NAT mental load. How to start—run multiple mutually-calling services from your project each in its own container, replace localhost:portN with direct container IP connections, clean up port mappings in .env along the way.

Comments

GitHub Issues · utterances