WWDC Quick Look đź’“ By SwiftGGTeam
中文 EN 日本語
Discover container machines

Discover container machines

SwiftLinuxContainerizationDeveloper Tools
Watch original video

Highlight

Container machine is a new feature in the Containerization framework. It provides a lightweight, persistent Linux environment on macOS, with automatic user mapping, file-system sharing, and seamless workflow integration.

Core Ideas

When developing Linux server apps on macOS, developers have long faced an awkward choice.

Traditional virtual machines provide a complete Linux environment and persistent state, but they start slowly and consume more resources. Container solutions such as Docker are lightweight and fast, but each launch starts from a fresh environment and changes are not persisted by default. More importantly, switching between either approach and macOS often means handling file sync, user permissions, path mapping, and similar issues that interrupt the development flow.

Apple’s Containerization framework, open sourced at WWDC25, offered a new direction: use lightweight virtual machines to achieve container-level isolation and startup speed. Built on that foundation, the Container machine feature introduced at WWDC26 combines the lightness of containers with the persistence of virtual machines, while reducing platform-switching friction through deep macOS integration.

Container machine is designed around four principles: lightweight and fast, easy to manage, persistent state, and native integration. It uses the same OCI image format as containers, starts almost instantly, and preserves changes. Automatic user mapping keeps the user name in the Linux environment aligned with macOS, the file system is shared automatically, and the current working directory maps across by default. Together, these choices make the Linux environment feel like a natural extension of macOS.

Details

Container machine is built on the Containerization framework. Each Container machine runs in its own lightweight virtual machine, uses a standard OCI image, and is a first-class feature of the container tool.

Basic Commands (4:41)

The container machine command provides an overview of available operations:

container machine

Key points:

  • Shows available operations such as create, run, and stop
  • Works as help output when used without arguments

Create a new Container machine:

container machine create --name demo --set-default alpine

Key points:

  • --name specifies the machine name
  • --set-default makes it the default machine, so later commands do not need to repeat the name
  • alpine is a common lightweight Linux image
  • Uses the same OCI image format as containers

Run a command inside a Container machine:

container machine run echo hi

Key points:

  • Runs a single command in the Linux environment
  • Returns after the command finishes

Check the difference in system type:

container machine run uname

Key points:

  • On macOS, uname returns “Darwin”
  • Inside Container machine, it returns “Linux”
  • This proves the code is running in a Linux environment

Automatic Integration Features (5:39)

Container machine automatically mirrors the macOS user name and current working directory:

# On macOS
whoami   # returns the current user name
pwd      # shows the current user directory

Running the same commands inside Container machine returns the same user name and path.

Key points:

  • Automatic user creation through user mapping
  • Automatic file-system sharing
  • Consistent working directory
  • No manual mapping configuration required

Start an interactive shell:

container machine run

Key points:

  • Starts an interactive session when used without arguments
  • Enters a complete Linux shell environment
  • Supports multi-step operations

Listing and Managing Machines (8:01)

container machine list

Key points:

  • Shows the names of all Container machines
  • Shows each machine’s IP address
  • Shows resource usage information
  • The IP address is used for network access

Cross-Platform Development Workflow (7:03)

The demo shows a typical cross-platform development scenario: edit code in Xcode on macOS, build and run it in a Linux environment, and test the result in Safari.

Project structure:

Package.swift
Source/
Public/    # Static assets

Run a Vapor server inside Container machine:

container machine run
swift run

Key points:

  • Accesses project files through the shared file system
  • Container machine has its own network
  • Access from macOS requires the machine’s IP address

The Vapor configuration needs to listen on an external interface by using the Container machine IP address.

Key points:

  • Modify the configuration in Xcode
  • Changes are immediately available inside Container machine
  • No restart or reload required

Workflow shown:

  1. Edit code in Xcode
  2. Build and run inside Container machine
  3. Access and test in Safari
  4. Modify the icon with Icon Composer
  5. Refresh Safari to see the update
  6. No file copy or sync operation required

Architecture (1:00)

The Containerization framework provides:

  • Storage APIs
  • Networking APIs
  • Execution APIs
  • A Linux init system

Each container gets virtual-machine-based isolation, with startup time below one second.

Key points:

  • Lightweight virtual machines provide performance benefits
  • Virtual-machine-level security isolation
  • Fast startup supports frequent context switching

Key Takeaways

  1. Local development environments for microservices

    • Use one Container machine per microservice, with independent toolchains and dependencies
    • Avoid “works on my machine” problems
    • Entry point: container machine create --name service-a

  2. CI/CD pipeline rehearsal

    • Use Container machine to reproduce the production Linux environment
    • Validate deployment scripts and configuration locally
    • Entry point: create a machine from the production OCI image

  3. Unified development for multi-language projects

    • Let macOS handle the frontend while Container machine runs backend services
    • Share project files without synchronization
    • Entry point: install an image with the toolchain for the relevant language

  4. Toolchain version isolation

    • Use different versions of Node.js, Python, or Go for different projects
    • Avoid version managers by giving each machine its own environment
    • Entry point: create a dedicated machine based on the toolchain version

  5. Secure sandbox testing

    • Test untrusted code in an isolated Linux environment
    • Virtual-machine-level isolation protects the host
    • Entry point: run test commands with container machine run

Comments

GitHub Issues · utterances