Fatbobman's Swift Weekly #072
Beyond X: The Swift Community Embraces Mastodon and BlueskyOn February 21, the Swift community officially launched its official account on Bluesky, while also posting its first message on its Mastodon account, which had been created back in 2022. On the surface, this may seem like just another typical social media update, but in reality, this decision has been under discussion and consideration within the Swift community for some time, and a series of recent events have accelerated this process. Since the privatization of Twitter, many users have been looking for alternative platforms, with Mastodon and Bluesky emerging as the main choices. However, due to its massive user base and deeply ingrained habits, X (formerly Twitter) still maintains significant influence. If a large portion of the social circle cannot be persuaded to move to a new platform, users might miss out on important communication opportunities. This has meant that the migration to other platforms has not had a significant impact on X, but rather forced many users to spread their attention across multiple platforms to keep content synchronized and maintain interactions. Recently, a series of actions by Elon Musk has once again prompted the community to deeply reconsider their choice of social media platforms. In last week’s blog post, Matt Massicotte strongly responded to Apple's decision to resume advertising on the X platform: he decided to suspend providing feedback and improvement suggestions to Apple. Moreover, since the Swift community still relies on X as the sole platform for information dissemination, he also announced he would pause his participation in Swift forums and Evolution discussions. This stance was widely supported by many developers, and to some extent, it sped up the Swift community’s decision to launch accounts on Mastodon and Bluesky. Considering Apple’s special position within the Swift community, the decision to expand social media channels at this point is a courageous one. As a mature open-source community, the Swift team has taken a pragmatic approach: neither abandoning the existing platform entirely nor sticking exclusively to one channel. By extending its reach to more platforms, the community has shown inclusivity and respect for users on different platforms. As a newsletter editor, after each issue is published, I make sure to tag the author's accounts on multiple platforms as a sign of respect. However, I also recognize that each developer has their preferred social platform. Therefore, I suggest content creators clearly indicate their primary platform of activity on their personal blog, so that I can better respect your choice and include your most frequently used platform account in the newsletter. Platform migration can be an expression of attitude, symbolizing dissatisfaction with the status quo and anticipation of change, or it may simply be a fresh attempt to explore a more suitable way of communication. But we must understand that everyone has their own considerations and freedom of choice. For those who choose to stay on their original platform, we should not make judgments or accusations lightly. After all, what truly matters is not which platform we choose, but how we maintain meaningful communication on our chosen platforms and continue to contribute value to the community. Previous Issue｜Newsletter Archive If you appreciate my work and want to promote your product to the Swift and iOS developer community, sponsoring my platform could be an excellent opportunity for you. Your support through Patreon, or Buy Me a Coffee helps keep this newsletter and blog running. Thank you for finding this content helpful! OriginalFrom Host to Serverless: A Blog Architecture Migration JourneyIn the past month and a half, I’ve made a series of adjustments to my blog, covering areas such as the publishing mechanism, code architecture, and layout design. These changes have not only enhanced the performance and user experience of the blog but also made content maintenance and updates more efficient. This article provides a brief overview of the key changes. Recent RecommendationsHow Swift's Server Support Powers Things CloudThings is a well-known task management app in the Apple ecosystem, relying on Things Cloud for seamless cross-device synchronization. Previously, the service was built on Python 2 + Google App Engine—while stable, it suffered from slow response times, high resource consumption, and a lack of static typing. Over a three-year refactor, the team fully migrated to Swift + Vapor, successfully running in production for a year. This transition resulted in three times lower computing costs, better performance, and improved development efficiency. Additionally, the move allowed them to replace their C-based push notification service, simplifying the architecture. In this article, Vojtech Rylko and Werner Jainek share their migration experience, offering valuable insights into server-side Swift development. Why You Should Keep Your Git Commits Small and MeaningfulVersion control is an essential part of modern software development, and well-structured commits can greatly enhance code management and team collaboration. Ideally, each commit should serve as a logical checkpoint—even if a feature is incomplete, the code should remain compilable with a clear change objective. In this article, Donny Wals emphasizes how small and meaningful commits help developers track changes, reduce debugging costs, and make Git history a valuable resource rather than a cluttered log. He also discusses the importance of using git rebase to clean up commit history and avoid unnecessary merge commits for better readability.
async let vs Task groupIn Swift’s structured concurrency model, both async let and Task Group can be used for parallel task management, but they have significant differences in lifecycle and behavior. Vitaly Batrakov provides a detailed analysis of their implementations and highlights edge cases that developers may overlook. He argues that when choosing a concurrency approach, developers should not only consider the number of tasks but also take into account error-handling strategies and lifecycle management to select the most suitable implementation. What to Test (and What Not to Test) in SwiftUISwiftUI’s declarative nature encourages developers to separate business logic and state management into ViewModels, but this does not mean that view behavior should go untested. In this article, Jon Reid explores the boundaries of SwiftUI view testing, focusing on key principles such as testing behavior instead of appearance, verifying UI communication, and testing UI components with logical conditions. Although SwiftUI does not provide official unit testing tools for views, developers can use ViewInspector to directly inspect SwiftUI view internals or leverage Snapshot Testing for visual regression testing. These tools help maintain stable and maintainable SwiftUI code without adding unnecessary architectural complexity. Creating Custom SF SymbolsSF Symbols in SwiftUI provide built-in support for variants, color modes, and animations, ensuring visual consistency across apps. If you need unique symbols while maintaining system compatibility, custom SF Symbols can be a great solution. In this article, Antonella Giugliano explains how to create custom SF Symbols by combining existing symbols, designing new ones using vector tools, and importing them into Xcode for seamless SwiftUI integration. Modern Concurrency and Legacy CodeSwift Concurrency with async and await offers a cleaner and more maintainable approach to asynchronous programming, but many teams are still tied to callback-based legacy code, making migration difficult. In this article, Omar Elsayed presents a low-risk, efficient migration strategy that introduces modern concurrency patterns without disrupting existing functionality. By gradually adopting Swift Concurrency and leveraging Swift Macros to automate the transition, developers can upgrade their codebase while maintaining stability. This approach provides a practical solution for teams looking to transition to Swift Concurrency without compromising development speed. 不止于 X：Swift 社区拥抱 Mastodon 和 Bluesky在 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 团队采取了务实的做法：既不激进地完全放弃现有平台，也不固守单一渠道。通过将信息覆盖扩展到更多平台，社区展现了对不同平台用户的包容和尊重。 作为一名周报编辑，每期周报发布后，我都会在多个平台标记作者的账号，以示敬意。然而，我也意识到，每位开发者都有自己偏好的社交平台。因此，我建议内容创作者在个人博客中明确标注主要活动平台，以便我更好地尊重你的选择，并在周报中添加你最常用平台的账号。 平台的转换可以是一种态度的表达，象征着对现状的不满和对改变的期待；也可能仅仅是一次全新的尝试，去探索更适合自己的交流方式。但我们要明白，每个人都有自己的考量和选择的自由。对那些选择留在原平台的人们，不应该轻易做出评判或指责。毕竟，真正重要的不是我们选择了哪个平台，而是我们如何在各自选择的平台上维持有意义的交流，继续为社区贡献价值。 如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 爱发电，Buy Me a Coffee 支持我的创作。 原创从 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 记录真正成为有价值的资源，而非混乱的日志。同时，他也提到合理使用
async let vs Task group在 Swift 的结构化并发中， 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 大会官网 了解更多活动详情和嘉宾名单。学生可以享受半价购票优惠。点击此处 可九折购买门票。
Welcome to my blog Fatbobman's Swift Blog( 肘子的Swift记事本 )
|
