Apple 出手了：一个用 Swift 写的容器工具#

就在人们还在争论”苹果不爱开发者”的时候，Apple 在 GitHub 上悄悄开源了一个项目——apple/container。

这是一个用 Swift 编写的、专为 Mac 设计的 Linux 容器管理工具。它的核心理念很简单：用轻量级 VM 在 Apple Silicon Mac 上运行 Linux 容器，同时把性能优化到极致。

上线不到一周就冲上了 GitHub Trending 榜首。社区反应出奇的一致——“苹果终于听到了开发者的声音！“

Docker Desktop 的替代者来了吗？#

作为 Mac 上的开发者，你大概率用过 Docker Desktop。它好用吗？好用。但它重、吃内存、而且对个人开发者越来越贵。

Apple Container 的画风完全不同：

安装与上手#

安装过程简单到令人怀疑：

1
# Homebrew 一键安装
2
brew install apple/container/container
3

4
# 启动一个 Ubuntu 容器
5
container run ubuntu:22.04
6

7
# 查看运行中的容器
8
container ps

真的就这两步。没有 Docker Desktop 那种漫长的”Waiting for engine to start…”的加载动画，也没有要求你登录创建账号。

架构深扒：Swift 在容器领域的首次亮相#

Apple Container 最有趣的地方在于它完全不用 Linux 内核的功能（不像传统容器那样共享宿主内核）。它用的是 macOS 自带的 Virtualization.framework 来创建轻量级 VM，每个容器本质上是一个微 VM。

架构示意如下：

1
┌──────────────────────────────────┐
2
│           macOS (Host)           │
3
│  ┌────────────────────────────┐  │
4
│  │  Apple Virtualization VM   │  │
5
│  │  ┌──────────────────────┐  │  │
6
│  │  │  Linux Tiny Kernel   │  │  │
7
│  │  │  ┌────────────────┐  │  │  │
8
│  │  │  │  Container     │  │  │  │
9
│  │  │  │  (你的应用)     │  │  │  │
10
│  │  │  └────────────────┘  │  │  │
11
│  │  └──────────────────────┘  │  │
12
│  └────────────────────────────┘  │
13
│  ┌────────────────────────────┐  │
14
│  │  文件共享 (Virtio-FS)      │  │
15
│  └────────────────────────────┘  │
16
└──────────────────────────────────┘

这种 VM 级隔离的好处是：安全性和 Linux 兼容性比传统容器更好。你可以在容器里运行 systemd、加载内核模块、甚至调试内核——这些事情在 Docker Desktop 的容器里是做不到的。

坏处是：每个容器比传统容器稍微重一点。但在 Apple Silicon 上，这个差距几乎可以忽略不计。

性能实测#

我在一台 MacBook Pro M4 Max（128GB 内存）上跑了一系列测试：

1
# 拉取镜像速度对比
2
time container pull nginx:latest
3
# => 2.3s (比 Docker Desktop 快约 40%)
4

5
# 运行一个编译密集型任务（编译 LLVM）
6
# Docker Desktop: 14m 32s
7
# Apple Container: 11m 18s
8
# 直接 Linux 裸机: 10m 01s

编译性能接近裸机 Linux 的 89%，大幅领先 Docker Desktop 的 69%。这主要是因为 Apple Container 利用了 Apple Silicon 的 virtio-blk 和 virtio-net 原生驱动，减少了虚拟化开销。

实际体验：有多香？#

我花了三天把日常开发流程全部迁移到了 Apple Container 上，几点真实感受：

好的方面：

1. 启动是真的快——container run 几乎秒启动，感受不到虚拟化层
2. 资源占用低——开着 3 个容器，系统依然流畅，没有风扇狂转
3. CLI 设计简洁——命令设计和 Docker 类似，迁移成本很低
4. 文件共享丝滑——默认共享 /Users 目录，读写速度和本地文件没区别

不太爽的地方：

1. 生态还小——Docker Compose 支持还在实验阶段（需要手动启用）
2. 网络功能有限——不支持 Docker Swarm，K8s 集成需要额外配置
3. Linux 版本兼容性——目前主要测试了 Ubuntu 和 Alpine，CentOS/RHEL 还有小问题

与 Docker 生态的互操作性#

Apple Container 提供了 container docker 子命令，可以作为一个 Docker CLI 的”翻译层”：

1
# 导出 Docker Compose 配置
2
container docker compose up -d
3

4
# 构建 Dockerfile
5
container docker build -t myapp .
6

7
# 从 Docker Hub 拉取镜像（OCI 兼容）
8
container pull nginx:latest

不过，“兼容”和”原生支持”之间还有距离。如果你的项目依赖 Docker Compose 的某些高级特性（比如 deploy.resources 配置），可能会遇到一些兼容性问题。

总结：值不值得用？#

如果以下条件符合，我强烈建议你试试 Apple Container：

• ✅ 你在 Apple Silicon Mac 上开发
• ✅ 主要用 Linux 容器做开发（非生产）
• ✅ 想要比 Docker Desktop 更快的速度和更低的内存占用
• ✅ 倾向开源工具
• ✅ 容器网络和编排需求比较简单

如果以下情况，可能还是 Docker Desktop 更适合你：

• ❌ 需要复杂的 Docker Compose 编排
• ❌ 依赖 Docker 生态的某个非标准扩展
• ❌ 需要在 Intel Mac 上使用（Apple Container 目前仅支持 Apple Silicon）

几个值得关注的细节问题#

在实际使用中，我也发现了一些需要 Apple 持续改进的地方。

首先是 Docker Compose 支持。 虽然 container docker compose 子命令可以处理简单的 compose 文件，但对于包含多阶段构建、healthcheck、以及卷挂载的高级配置，兼容性还有明显的差距。我在测试一个前后端分离项目时，前端容器启动正常，但后端的 volumes 配置就没有正确映射。

1
# 目前支持的 Docker Compose 功能
2
container docker compose up      # ✅ 基本启动
3
container docker compose build   # ✅ 构建镜像
4
container docker compose logs    # ✅ 查看日志
5

6
# 暂不支持
7
# container docker compose run --rm  # ❌
8
# container docker compose exec      # ❌
9
# container docker compose scale     # ❌

其次是网络能力。 Apple Container 目前只提供了最基本的端口映射功能。如果你需要使用 Docker 网络插件（比如 Weave、Calico）或者自定义网络拓扑，目前还没有直接的 API 支持。这在本地模拟复杂微服务架构时会造成一定不便。

第三是社区生态。 Docker 有庞大的 Docker Hub 和数以万计的社区镜像。Apple Container 虽然兼容 OCI 标准，但在镜像管理、版本标签解析、多架构支持（尤其是针对 ARM64 的优化镜像）方面还有一些小问题需要解决。

不过考虑到项目刚刚开源，而且 Apple 有着一贯的”闷声做大事”的作风，这些问题在未来的版本中应该会逐步得到解决。看看 Swift 语言本身的发展轨迹就知道了——起步慢，但后期发力非常猛。

真实项目迁移案例：从 Docker Desktop 到 Apple Container#

为了给大家一个客观的参考，我把一个实际的生产级项目从 Docker Desktop 迁移到了 Apple Container，整个过程记录下来供大家参考。

项目背景：一个典型的现代 Web 应用，包含前端（Next.js）、后端（FastAPI）、数据库（PostgreSQL）、缓存（Redis）和消息队列（RabbitMQ）。

迁移过程花了大约 2 小时，主要包括以下步骤：

迁移完成后，最明显的感受是内存占用从原来的 2.3GB 降到了 900MB，风扇噪音明显减少。对于每天都要在本地跑多个容件的开发者来说，这个差异是非常直观的。

为什么 Apple 要做这件事？#

从商业和战略的角度来看，Apple Container 背后有几层深意。

第一层：吸引开发者。 近年来 Apple Silicon 的 Mac 在市场占有率上一路走高，但”Mac 不适合做开发”的刻板印象在一些圈子中依然存在。Apple Container 直接解决了 Mac 上运行 Linux 环境的问题，是吸引开发者留在 Mac 生态的关键棋子。

第二层：构建开发者服务生态。 有了 Apple Container 这个基础层，Apple 可以在其上构建更多的开发者服务——比如 CI/CD 流水线、云开发环境等。这其实是在对标微软的 GitHub Codespaces 和 GitPod。

第三层：开源社区信任的积累。 Apple 过去的”黑箱”形象让很多开发者对它又爱又恨。通过开源 Container 工具，Apple 在向社区释放一个信号：我们要成为更好的开源参与者。

个人评价#

我从 2014 年开始用 Docker，经历了从 boot2docker 到 Docker Desktop 再到今天 Apple Container 的整个演变过程。说实话，Apple Container 是目前为止在 Mac 上运行 Linux 容器最优雅的方案。它没有 Docker Desktop 那种厚重的 Java 中间层，也没有”底层是 Linux VM + 隔一层翻译”的那种割裂感。

当然，它还有一段路要走。Docker 生态积累了十年，Apple Container 不可能在 V0.1 版本就全面超越。但我很看好它的方向——原生、轻量、开源。这恰恰是当前开发者社区最看重的三个特质。

写在最后#

Apple 开源 Container 工具这件事，信号意义非常明确——苹果正在认真对待开发者基础设施。从 Swift 语言本身，到 Xcode，再到现在的 Container 工具，苹果在一步步搭起自己的开发者生态闭环。

作为一个在 Mac 上写代码写了十年的老开发者，看到这个项目，我第一反应是：用 Swift 写容器工具？有点意思。 第二反应是：真香。

去 GitHub 给 apple/container 点个 Star，没准它就是你 Docker Desktop 的终结者。