摘要：苹果正式宣布将 Swift Build 开源，并纳入 Swift 项目，致力于为所有 Swift 用户提供更强大且统一的跨平台构建体验。Swift Build 作为 Xcode 的底层构建引擎，已为数百万 App 和自家操作系统构建流程提供支持，开源后也可面向

编译 | 核子可乐、Tina

苹果正式宣布将 Swift Build 开源，并纳入 Swift 项目，致力于为所有 Swift 用户提供更强大且统一的跨平台构建体验。Swift Build 作为 Xcode 的底层构建引擎，已为数百万 App 和自家操作系统构建流程提供支持，开源后也可面向 Linux、Windows 等平台。

目前，Swift Build现已在 GitHub 上发布， 采用 Apache 2.0 许可。

它支持插件扩展，兼容包括 Android、Apple 平台、Linux、QNX（嵌入式操作系统）和 Windows 在内的多种目标平台。构建系统的功能包括支持库、命令行和 GUI 应用程序等项目类型，以及在构建 Swift 和 C 代码时进行优化以最大程度地提高并行性。苹果表示，未来将与开源社区紧密合作，推动在“所有平台”上实现统一的构建执行引擎。

苹果开源 Swift 构建系统：

对开发者意味着什么

从苹果发布的博文来看，Swift Build 目的是统一 Xcode 和现有开源 Swift 包管理器（Swift PM）的构建系统。

构建系统是一段位于编译器之上的代码，主要负责协调源文件如何被送入编译器。其核心任务是确保源代码按照模块之间的依赖顺序进行构建，并合理安排编译任务，以最大化并行处理的效率。

既然该构建系统的代码已经在 GitHub 上开源，是否意味着大家可以不使用 Xcode 或 Xcode Build 来构建 iOS 应用？例如，是否能够使用第三方 IDE（如 Cursor）来完成构建？答案是否定的。原因在于，Swift 构建系统只是 Xcode 用于构建 iOS 应用的完整构建系统的一部分。构建 iOS 应用不仅涉及编译 Swift 代码，还包括处理资源文件、管理权限配置、代码签名等复杂且敏感的流程。这些任务只有 Xcode 能够正确处理，部分原因在于其中包含了一些 Apple 尚未开源的专有步骤。坦率而言，这些内容与 Apple 的核心业务密切相关，因此不太可能被开源。

既然无法完全替代 Xcode，那么 Apple 开源 Swift 构建系统的意义何在？实际上，这项开源举措主要有两个方面的重要价值。

首先，过去存在两套用于构建 Swift 项目的不同构建系统：一套是 Xcode 内置的（本次开源的正是这一套），另一套则是 Swift Package Manager 独立使用时的构建系统。当两个工具被设计用于完成相同任务时，往往会出现一些边缘场景，导致它们的行为不一致，进而影响开发体验。正如 Apple 软件工程师 Owen Voorhees 在官方博文中提到的，这种差异会在两种实现的行为不一致时“让用户感到困惑”。

开源 Xcode 使用的 Swift 构建系统，有助于推动其成为所有平台通用的构建工具。这对于确保 Swift 生态系统的健康性和可靠性至关重要，能够让开发者确信，无论在何种环境下构建代码，结果始终一致。

另一个令人兴奋的意义在于，它为 Swift 开源社区的发展释放了积极信号，推动了生态系统的健康成长。

在此之前，不少网友认为 Swift 的最大问题在于开源社区的活跃度不足以及 Chris Lattner 的离开所带来的影响。

一个典型的评论

Lattner 作为 Swift 的灵魂人物，离开后项目的技术方向和发展节奏一度陷入不确定性，而开源社区由于缺乏统一的技术愿景和明确的治理机制，导致贡献分散、协作效率不高，不可避免在关键技术决策上会产生分歧和停滞。

然而，随着苹果开源 Xcode 使用的 Swift 构建系统，从长久来看，这种局面或许会逐渐发生改变。这一举措不仅降低了社区开发者参与底层工具改进的门槛，也为 Swift 的技术生态注入了新的活力。开发者可以更深入地了解构建系统的工作机制，提出优化建议，甚至直接参与核心代码的开发。更重要的是，这标志着苹果在 Swift 开源战略上的新态度，表明其愿意在商业利益与技术开放之间寻求新的平衡，推动 Swift 成为真正意义上由社区和企业共同驱动的现代编程语言。

夹在开源和苹果公司之间的

编程语言

Swift 是由苹果开发工具高级总监 Chris Lattner 倾力打造的编程语言，最初由他在业余时间独立完成基础框架。然而，由于苹果高管团队大多出身于与乔布斯紧密关联的 NeXT 团队，Swift 的立项经历了复杂的内部协商和政治博弈。在 2014 年 WWDC 正式发布前，Swift 项目严格保密，仅有 250 名内部员工知情。Lattner 旨在打造一种简单、需求驱动的语言，并在 2015 年成功说服以保密著称的苹果公司将 Swift 开源，成就了一项令人难以置信的壮举。

多年来，Swift 语言由三股相互制约的力量共同推动：

Lattner 本人，他努力推动自己的核心愿景并把控技术债。

开源社区，他们从内心深处希望 Swift 语言能够良好发展，但总体上的表现只能说混乱和糟糕来形容。

苹果公司，这位负责为 Swift 团队支付薪水的行业巨头对于盈利有着坚定不移的追求。

2017 年，Lattner 离开苹果投身于人工智能领域研究。此后，Swift 逐渐进入由苹果主导、开源社区协同的全新发展阶段。失去了 Lattner 这位核心推动者，Swift 面临着新的挑战：既要在开源社区的技术多元化中保持一致性，又需在苹果的商业战略中找到平衡点，逐步探索自身的独立性与可持续发展路径。

从本质上讲，编程语言治理的核心在于协调各项激励措施。每一种编程语言都面对三大主体受众：

每天使用该语言的 最终用户开发者。

提交（和实现）语言提案的 社区。

拥有最终决定权的 指导小组。

其中最终用户开发者只希望能用上优秀的语言。语言本身就是最直接的评判依据，他们会用键盘投票。这个群体有数百万人，但由于语言转换成本极高，所以最终用户们的影响力其实最小：大多数人不愿放弃自己积累多年的开发经验。

社区则是由最热情的最终用户开发者外加由指导小组统辖的一批全职团队组成。这股力量往往有着最纯粹的动机：希望改进自己喜爱的语言。然而，他们也面临着自己的阻力和困扰：

简历驱动开发（即开发经验只为提升个人就业能力服务）促使工程师们单纯出于增强个人竞争力而参与讨论，他们虽然活跃度很高但并不真正关心语言本身的未来。

避重就轻：这是一种常见的行为驱动因素。与其专注于提案核心的技术设计，不如选择阻力最小的路径，即将精力集中在语法和命名等琐碎的细节身上。

在这样的力量分布之下，掌握决策权的指导小组很容易成为左右项目方向的主导者，并可根据治理结构采取截然不同、反复横跳的激励措施。

相比之下，Python 和 Rust 等语言的指导小组则由最具影响力的社区成员组成。他们的激励措施虽不完美，但目标却稳固且统一——只做“对语言最有利”的事。Kotlin 则属于另外一种情况，其背后的企业具有盈利动机，希望依托这种语言推广自家 IDE（JetBrains）并提高 Android 开发者的数量和生产力（谷歌）。幸运的是，这些治理层面的激励措施与其他各方的基本立场高度吻合——让语言本身变得更好，有利于全面实现这些目标。可 Swift 的情况则完全不同……

作为 Swift 背后唯一的主宰与挟制者，苹果承担大部分核心团队成员的薪水，并有权随意调整项目领导团队的组织结构。而苹果的动机也非常纯粹：为股东们实现利益最大化。

从某种程度上看，这种追求利益的动机其实跟数百万 iOS 开发者这一弱势群体其实保持着统一。语言质量越高，能够吸引到的 iOS 工程师就越多，这对应着更多应用产品、也将带来更可观的 App Store 销售收益和硬件产品人气。

但这种激励措施，同时也令苹果公司与希望推动语言发展的开源社区之间爆发了危险的冲突。

Swift 5.1 就是苹果漠视社区诉求的典型案例。该版本引入了一系列不透明的结果类型、隐式返回和属性打包器，甚至在未经任何铺垫的情况下直接往编译器里塞函数构建器！

这些功能共同构成了 SwiftUI 的语法主干，而 SwiftUI 正是苹果眼中代表未来的全新 UI 框架。苹果设计了了套内部时间表，把各项功能是否获批及发布时间安排得明明白白。至于社区想要的公平发言权，那是门儿也没有。

最终结果就是，SwiftUI 的观感确实比显式返回的 View 上了个台阶。SwiftUI 更简单，无需将子视图附加到父结果上。但这些改变也让整个语言变得更复杂、编译器更易出错。

很多朋友可能还记得，Swift 并发宣言早在 2017 年就已经设定。但在分配团队开发资源时，苹果认为在 2019 年发布更时髦的全新 UI 框架才是当务之急，于是乎 Swift 并发机制就一路被推迟到了 2021 年。

而且回顾 Chris Lattner 最初为 Swift 设定的设计理念，并与当前的 Swift 版本进行对比，可以看出一些显著的差异：

简单且可以组合的语言（复杂功能无法组合）。

渐进式披露（现在的 Swift 有 217 个关键字）。

一种需求对应一种实现方法（结构构建器和宏）。

尽管 Lattner 于 2017 年离开苹果，他仍然在 Swift 核心团队中为项目贡献力量，直至 2021 年。最终选择离开的原因，源于他对语言发展前景的担忧和多次未被采纳的意见：

……经过几次讨论，结果仍不尽人意。我正式提出的审查意见和担忧被决策者单方面忽略，再加上跟核心团队的合作过程一直不够透明，最终我意识到自己纯粹是在浪费时间。

……部分社区成员也反映他们不了解提案的背后动机，也没人愿意听取他们的意见。

在多重压力下（包括自上而下的目标设定、固定的开发时间表、庞大的技术债和 Bug 列表，以及内部审查流程的限制），Swift 社区的沟通机制逐渐出现了不平衡的倾向。等到外部开发者感知到这些变化时，很多决策早已深入推进，难以逆转。这种固化的决策流程往往导致项目方向缺乏灵活性，无法有效回应社区的真实需求，最终使得各方都感到不够满意。

虽然苹果在公开场合强调对开源社区的支持，并鼓励开发者对新版本提案提出反馈，但在实际操作中，内部提案的优先级仍然占据主导地位。这种偏向性反映了苹果对自身产品战略的高度关注，尤其是在 UI 框架和跨平台能力等核心领域。这些战略优先事项不仅推动了苹果技术生态的发展，也进一步巩固了其“围墙花园”式的生态体系。

另外，Chris Lattner 曾在播客节目中多次谈到 Swift 编译器的技术债积压问题。其实技术债在项目早期是不可避免的，他当初领导的小团队至少成功让数百万开发者获得了令人满意的全新语言选项，也曾顺利把整个开发环境从 Objective-C 和 Swift 2 迁移到了 Swift 3。然而，随着 Lattner 的离开，Swift 编译器的技术债逐渐积累，问题的复杂性与日俱增。如今，这些技术债已形成了系统性挑战，短期内难以彻底解决。

之前 Lattner 离开 Swift 团队的重大决定，苹果乃至更广泛的开源社区都感受到了冲击和震荡。虽然还有其他影响因素，但此事确实让各方意识到削弱独裁程度、增强治理透明水平的重要意义。

虽然苹果在推动这些改革的过程中仍保留着一定的主导权，但其对外部声音的接纳程度显著提高。Swift 为此借鉴了 Rust 模型的治理思路——设置专门的指导小组和工作组，在团队中引入来自苹果以外的成员。

“最重要的是，每位 Swift 使用者都是我们庞大社区中极富价值的一员”，这话说得可太招人喜欢了。

现在平台指导小组也已经建立起来，负责实现 Swift 在 Windows 和 Arduino 上的应用。苹果也开始在自己的某些后端系统上对 Swift 做内部测试，探索每秒处理数百万条请求的可能性。虽然这并非完全出于利他动机，但客观上 Swift On The Server 工作组的付出和成果仍然值得肯定。

苹果也正在努力将 Foundation 重写成开源 Swift 包，以便其能够被顺利移植到所有平台之上。不少新库（例如 AsyncAlgorithms）也以依赖包的形式发布，而不再像之前的标准库那样与操作系统牢牢绑定。

最后，Swift Build 的开源标志着 Swift 生态系统迈向更加成熟和开放的关键一步。正如官方所强调的那样：“将 Xcode 的构建引擎贡献给 Swift 项目，并与 Swift 编译器一同在开源环境中开发，旨在为解决现有问题、提升所有 Swift 用户的构建体验提供强大支持。此次发布为 SwiftPM 带来了在所有平台上实现统一构建执行引擎的机会。这一变化对用户而言是无感的，既能保持与现有包的完全兼容，又能提供一致的跨平台体验。同时，它为各平台和工具的功能扩展与改进奠定了坚实基础，进一步释放出新的性能优化潜力和开发者友好特性。”

参考链接：

https://news.ycombinator.com/item?id=42899703

声明：本文为 InfoQ 翻译，未经许可禁止转载。

今日好文推荐

👉OpenAI“背水一战”：紧急上线Deep Research，比DeepSeek强三倍？网友直呼AI开源大战要来了！

👉一场由DeepSeek引发的技术裂变，正在重写AI时代的权力分配方程式

👉DeepSeek霸榜一周：奥特曼终于承认在开源问题上处于“历史错误的一边”；迅雷斥资5亿收购“直男社区”虎扑 | Q资讯

👉美国终于要对 DeepSeek 下手了？美官员称 DeepSeek 是“偷窃”

会议推荐

在 AI 大模型技术如汹涌浪潮席卷软件开发领域的当下，变革与机遇交织，挑战与突破共生。2025 年 4 月 10 - 12 日，QCon 全球软件开发大会将在北京召开，以 “智能融合，引领未来” 为年度主题，汇聚各领域的技术先行者以及创新实践者，为行业发展拨云见日。现在报名可以享受 8 折优惠，单张门票立省 1360 元，详情可联系票务经理 18514549229 咨询。

来源：极客邦科技