在 2 月 21 日，Swift 社区正式在 Bluesky 上开设了 官方账户，同时在其早在 2022 年就创建的 Mastodon 账户 上首次发布了信息。表面上看这似乎只是一个普通的社交媒体动态，但实际上这个决定在 Swift 社区中已经经过了一段时间的 讨论和酝酿，最近的一系列事件更是加速了这一进程。
自 Twitter 私有化以来，大量用户开始寻找替代平台，其中 Mastodon 和 Bluesky 成为了主要的选择。然而，由于其庞大的用户基数和根深蒂固的使用习惯，X（原 Twitter）仍然保持着强大的影响力。如果无法说服社交圈中相当比例的人一同迁移到新平台，用户就可能错失重要的交流机会。这导致平台迁移并未对 X 造成很大影响，反而使许多用户不得不在多个平台间分散精力，维持内容的同步发布和互动。
最近，伊隆马斯克的一系列举措再次引发了社区对社交媒体选择的深度思考。在上周的 博文 中，Matt Massicotte 针对苹果重新在 X 平台投放广告的决定做出了强烈回应：他决定暂停向苹果提供问题反馈和改进建议。同时，由于 Swift 社区仍然将 X 作为唯一的信息发布渠道，他也表示将暂停参与 Swift 论坛和 Evolution 的讨论。这一立场获得了众多开发者的认同，也在一定程度上促使 Swift 社区加快了开通 Mastodon 和 Bluesky 账户的步伐。
考虑到苹果在 Swift 社区中的特殊地位，社区此时选择扩展社交渠道是一个需要勇气的决定。作为一个成熟的开源社区，Swift 团队采取了务实的做法：既不激进地完全放弃现有平台，也不固守单一渠道。通过将信息覆盖扩展到更多平台，社区展现了对不同平台用户的包容和尊重。
作为一名周报编辑，每期周报发布后，我都会在多个平台标记作者的账号，以示敬意。然而，我也意识到，每位开发者都有自己偏好的社交平台。因此，我建议内容创作者在个人博客中明确标注主要活动平台，以便我更好地尊重你的选择，并在周报中添加你最常用平台的账号。
平台的转换可以是一种态度的表达，象征着对现状的不满和对改变的期待；也可能仅仅是一次全新的尝试，去探索更适合自己的交流方式。但我们要明白，每个人都有自己的考量和选择的自由。对那些选择留在原平台的人们，不应该轻易做出评判或指责。毕竟，真正重要的不是我们选择了哪个平台，而是我们如何在各自选择的平台上维持有意义的交流，继续为社区贡献价值。
原创
从 Host 到 Serverless: 博客架构升级实践
在过去的一个半月里，我对博客进行了一系列的调整，涉及发布机制、代码架构和版式设计等多个方面。这些调整不仅提升了博客的性能和用户体验，也让内容维护和更新变得更加高效。本文将简单记录一下本次调整的主要内容。
近期推荐
Swift 如何为 Things Cloud 提供服务器支持 (How Swift’s Server Support Powers Things Cloud)
Things 是苹果生态下的知名任务管理应用，依赖 Things Cloud 提供跨设备同步。此前，该服务基于 Python 2 + Google App Engine，尽管稳定，但面临响应慢、资源占用高、缺乏静态类型等问题。团队经过三年重构，全面迁移至 Swift + Vapor，并成功在生产环境运行一年，带来了计算成本降低 3 倍、性能提升、开发效率提高等显著收益，同时替换了原有的 C 语言推送服务，使架构更加简洁高效。在本文中，Vojtech Rylko 和 Werner Jainek 分享了 Things Cloud 迁移到 Swift 的过程，为服务器端 Swift 开发提供了宝贵的实战经验。
为什么你的 Git 提交应当精简且有意义 (Why You Should Keep Your Git Commits Small and Meaningful)
版本控制已经成为现代项目中不可或缺的部分，良好的 commit 习惯能极大提升代码管理和团队协作的效率。理想情况下，每个 commit 应该是一个逻辑上的“检查点”，即使功能未完成，代码仍能编译，并具备清晰的变更目标。在本文中，Donny Wals 强调了小而有意义的 commit 如何帮助开发者追踪历史、减少调试成本，并使 Git 记录真正成为有价值的资源，而非混乱的日志。同时，他也提到合理使用 git rebase 进行历史优化，避免杂乱的 merge commit，提高可读性。
随着 AI 编程工具的普及，代码生成速度加快，commit 频率和粒度的把控成为新的挑战。如何在清晰的历史记录与流畅的开发体验之间找到平衡，值得开发者深入思考。
async let vs Task group
在 Swift 的结构化并发中，async let 和 Task Group 都可以用于并行任务管理，但它们的生命周期和行为存在显著差异。Vitaly Batrakov 详细分析了两者的实现方式，并指出了开发者容易忽略的边界情况。作者认为，开发者在选择并发方案时，不仅要考虑任务数量，还需要结合错误处理策略、生命周期管理等因素进行权衡，以选择最合适的实现方式。
SwiftUI 中该测试什么？不该测试什么？ (What to Test (and What Not to Test) in SwiftUI)
SwiftUI 的声明式特性鼓励开发者将主要逻辑和状态抽离到 ViewModel 进行测试，但这并不意味着视图行为本身不需要测试。Jon Reid 在这篇文章中探讨了 SwiftUI 视图测试的边界，包括：测试行为，而非外观；测试 UI 传递的信息；测试包含逻辑判断的 UI 组件。尽管 SwiftUI 没有提供官方的视图单元测试工具，但开发者可以借助 ViewInspector 直接检查 SwiftUI 视图的内部状态，或使用 Snapshot Testing 进行视觉回归测试。这些工具让我们在不增加架构复杂度的前提下，确保 SwiftUI 代码的稳定性和可维护性。
创建自定义 SF 符号 (Creating Custom SF Symbols)
SF Symbols 在 SwiftUI 中不仅提供了变体、色彩模式和快捷动画等功能，还能确保图标的视觉一致性。如果想要创建独特的符号，同时保持对系统特性的支持，可以考虑自定义 SF Symbols。在本文中，Antonella Giugliano 详细介绍了自定义 SF Symbols 的方法，包括：组合现有符号、使用矢量编辑工具创建新符号，以及导入 Xcode 以在 SwiftUI 中使用。
🪜 现代并发与遗留代码 (Modern Concurrency and Legacy Code)
在现代 iOS 开发中，Swift Concurrency（async/await） 提供了更清晰、更可维护的代码结构，但许多团队仍受限于基于回调（callback-based）的旧代码，难以直接迁移。本文中，Omar Elsayed 提供了一种低风险、高效的迁移方案。在不影响现有功能的前提下，逐步引入现代并发模式，并最终借助 Swift Macros 实现自动化转换。对于希望在保证代码稳定性的前提下，升级到 Swift Concurrency 的开发者，这是一个值得借鉴的实践路径。
Let’s Vision 2025
请访问 Let’s Vision 大会官网 了解更多活动详情和嘉宾名单。学生可以享受半价购票优惠。点击此处 可九折购买门票。
