Fatbobman's Swift Weekly #069
Fireworks and Drones
Weekly Comment
Fireworks and Drones
This year, I experienced a quieter Spring Festival than usual.
According to ancient Chinese legend, there was a mythical beast called Nian—a ferocious creature with long antennae that would terrorize humans. Every Lunar New Year's Eve, as the old year gave way to the new, Nian would emerge to wreak havoc. However, the beast feared three things: the color red, flames, and loud noises. To ward it off, people would paste red couplets on their doors, set off firecrackers, and keep their lights burning throughout the night. This tradition evolved into what we now call "Guo Nian" (celebrating the New Year).
For Chinese people, the New Year has always been inseparable from the brilliance of fireworks and the lingering scent of sulfur in the air. In recent years, however, many cities have restricted firework displays for environmental and safety concerns. Even in my city, where fireworks were traditionally unrestricted, core urban areas faced new regulations this year. While the city has indeed grown quieter, something of the festive spirit seems to have dimmed with the silence.
With advances in drone technology, many celebrations now feature choreographed drone formations in place of traditional fireworks. The first time I witnessed thousands of synchronized lights painting three-dimensional patterns across the night sky, I was genuinely awestruck. Yet over time, compared to fireworks, these displays began to feel somehow lacking in spirit. While drones execute their perfectly programmed routines, fireworks—despite their occasional imperfections—spark deeper wonder in their brief, explosive brilliance. This perhaps reflects a broader truth about art: overly precise expressions can limit imagination and audience engagement.
Technological progress need not demand absolute precision and order. Life's most memorable moments often spring from the unexpected and unpredictable. Drone shows and robotic performances are certainly products of our time, driving innovation and delivering impressive spectacles. Yet they should complement tradition rather than replace it. Today's cutting-edge technology may seem commonplace tomorrow, while the "primitive" rituals that have coursed through our veins for centuries—these are what truly sustain a civilization's soul.
Finding harmony between safety, environmental protection, cultural heritage, and technological advancement remains an ongoing challenge—one that deserves our continued exploration.
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!
Recent Selections
The Next Chapter in Swift Build Technologies
Although Swift has been open source for many years, Xcode and Swift Package Manager (SwiftPM) have long used different build engines. This not only led to inconsistent build experiences but also prevented non-macOS developers from accessing many of Xcode's unique build features. On February 1, 2025, Apple made a significant move by open-sourcing Swift Build, a powerful build engine based on the llbuild project. It supports various product types (such as libraries, command-line tools, and GUI applications) and maximizes parallel build efficiency through build graph optimizations. This provides a unified build experience, improves development efficiency, and further enhances Swift's cross-platform capabilities, especially for Linux and Windows. Apple also plans to collaborate with the community to unify the build system, laying the foundation for future performance optimizations and new features. Written by Owen Voorhees.
A Swift Concurrency Glossary
Swift has introduced many new terms and concepts for concurrent programming. Matt Massicottei organizes these in a glossary format, with each term including its type, purpose, introduction version, and author commentary. Massicotte not only defines the terms but also provides usage scenarios, precautions, and further explanations to help developers avoid common pitfalls. With clear explanations and examples, the article lowers the learning curve for Swift concurrency programming, encouraging more developers to adopt this model. For those looking to master Swift concurrency, this article is an essential reference.
Multiplatform Development for Apple Devices
Although SwiftUI offers many conveniences for multiplatform development, Apple's "Learn once, apply anywhere" design philosophy requires developers to optimize and adjust their projects for different platforms. In this article, Darryl Bayliss shares his experience migrating the Christmas Chill project from UIKit to SwiftUI, adding Apple Vision Pro support, using conditional compilation blocks, and leveraging build phases for dependency injection. Through these steps, he demonstrates how to utilize SwiftUI's cross-platform capabilities while optimizing for each platform.
Choosing the Best Way to Send Emails in an iOS App
On iOS, developers have multiple options for sending emails within their apps. Douglas Hill analyzes the pros and cons of each method, helping developers choose the best approach based on their app's needs. Hill's recommendations are:
ShareLink/UIActivityViewController: Suitable for general sharing scenarios, supporting multiple sharing methods (e.g., email, messaging apps), but not ideal for sending to specific addresses.
mailto links: Ideal for prefilling recipient, subject, and body fields, with cross-platform support (iOS, macOS, visionOS) and compatibility with the user's default email app, but does not support attachments.
MFMailComposeViewController: Best for sending attachments or prefilling email content, but limited to iOS devices and dependent on Apple Mail.
Understand Photo Storage Model on Apple’s Photos App and PhotosKit
As the developer of PhotonCam, Weichao Deng delves into the workings of PhotosKit in this article, comparing Android and iOS photo storage and processing based on his Android development experience. The article explains the roles of PHAsset and PHAssetResource, as well as how PhotosKit manages multiple versions of photos and auxiliary data (e.g., Apple/ISO Gain Map, Segmentation Matte). Additionally, it offers practical advice for cross-platform developers, emphasizing the need to ensure consistency in photo storage models when designing and developing photo apps.
Provide macOS System-wide Services from Your App
System-wide services allow macOS apps to extend their functionality across the entire system, enabling users to invoke app features via context menus or the Services menu from any application. Natalia Panferova uses her utility app EncodeDecode as an example, detailing how to define a service provider class, register the service, and configure the Info.plist file to implement system-wide URL encoding and decoding. The article also provides testing and debugging tips, such as using the pbs tool to verify service registration, making it a valuable resource for developers looking to integrate system-wide services into their macOS apps.
肘子的话
烟火与无人机
今年我过了一个安静的春节。
相传在上古时期，中国有一种叫“年”的怪兽，头长触角，凶猛异常。每到农历年新旧交替的除夕这天，“年”兽都要出来伤害人类。但由于“年”兽最怕红色、火光和炸响，因此，每年除夕家家张贴红对联、燃放爆竹，户户烛火通明，以此来驱赶“年”兽。这便是“过年”一词的由来。
对于中国人而言，年味总是与烟花的绚丽和空气中淡淡的硫磺味息息相关。然而近些年来，为了环境与安全考虑，越来越多的城市对燃放烟火做出了限制。即便是像我所在的这样往年几乎从不禁放的城市，今年也对核心区域进行了管控。如此一来，城市确实安静了许多，但年味似乎也随之淡去。
随着无人机技术的发展，越来越多的庆典活动开始用无人机编队取代传统烟火。初次观看时，数千个光点在夜空中勾勒出流动的立体图案，那种震撼确实令人惊叹。但时间久了，与烟火相比，总觉得少了几分灵气。相比那些经过精密编程的无人机表演，烟火虽偶有瑕疵，却在绽放生命最后一刻的灿烂中带给人更多遐想。这也许印证了很多艺术形式的共同特点：过于具象的表达反而会限制观众的想象力与参与感。
科技的进步并不意味着一切都要追求精准和秩序。生活中很多难忘的瞬间，恰恰来自那些意外与不确定。无人机表演、机器人舞蹈诚然是与时俱进的产物，这些创新确实推动了科技与产业的发展，也的确能带来惊艳的视觉体验。但它们不应成为传统形式的替代品，而应是一种合理的补充。今天看来多么先进的技术，或许几年后就显得平平无奇。反而是那些流淌在血液里，经过千百年传承的"不先进"活动，才是一个民族乃至人类文明得以延续的重要载体。
在安全、环保、人文、科技之间寻找平衡，这是一个需要我们继续探索的永恒课题。
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 爱发电，Buy Me a Coffee 支持我的创作。
近期推荐
Swift 构建技术的新篇章 (The Next Chapter in Swift Build Technologies)
尽管 Swift 已经开源了很多年，但长期以来 Xcode 和 Swift Package Manager (SwiftPM) 使用不同的构建引擎。这不仅造成了构建体验的不一致，而且对于非 macOS 开发者也无法享受到很多 Xcode 独有的构建功能。Apple 在 2025 年 2 月 1 日发布的一个重要举措：开源 Swift Build。这是一个基于 llbuild 项目的强大构建引擎，支持多种产品类型（如库、命令行工具、GUI 应用等），并通过构建图优化最大化并行构建效率。如此一来，不仅提供了统一的构建体验，还提升了开发效率，并进一步增强了 Swift 的跨平台能力，特别是在 Linux 和 Windows 上的支持。Apple 还计划与社区合作，完成构建系统的统一工作，为未来的性能优化和新功能奠定基础。本文由 Owen Voorhees 撰写。
Swift 并发编程术语表 (A Swift Concurrency Glossary)
Swift 为并发编程引入了不少的新术语和新概念。Matt Massicottei 通过本文对这些内容进行了集中梳理。文章以术语表的形式组织，每个术语都包含类型、用途、引入版本和作者的评论。Massicotte 不仅列出了术语的定义，还提供了使用场景、注意事项和进一步的解释，帮助开发者避免常见的陷阱。通过清晰的解释和示例，文章有助于降低 Swift 并发编程的学习曲线，推动更多开发者采用并发编程模型。对于想要掌握 Swift 并发编程的开发者来说，这篇文章是一个不可或缺的参考资料。
苹果设备的多平台开发 (Multiplatform Development for Apple Devices)
尽管 SwiftUI 为适配多平台提供了诸多的便利，但由于苹果的“Learn once, apply anywhere”设计理念，开发者仍需要针对不同的平台对项目做有针对性的优化和调整。在本文中，Darryl Bayliss 分享了他将项目 Christmas Chill 从 UIKit 迁移到 SwiftUI、添加 Apple Vision Pro 支持、使用条件编译块以及利用构建阶段进行依赖注入等技术细节。通过这些步骤，作者展示了如何利用 SwiftUI 的跨平台能力，同时针对不同平台进行优化。
在 iOS 应用中选择最佳邮件发送方式 (Choosing the Best Way to Send Emails in an iOS App)
在 iOS 上，开发者可以选用多种方式在应用中发送邮件。Douglas Hill 分析了每种方法的优缺点，帮助开发者根据应用需求选择最合适的方案。Hill 的建议如下：
ShareLink/UIActivityViewController：适合通用分享场景，支持多种分享方式（如邮件、消息应用等），但不适合需要发送到特定地址的场景。
mailto 链接：适合需要预填收件人、主题和正文的场景，跨平台支持（iOS、macOS、visionOS）且支持用户默认的邮件应用，但不支持附件。
MFMailComposeViewController：适合需要发送附件或预填邮件内容的场景，但仅限于 iOS 设备且依赖 Apple Mail。
🪜 理解 Apple Photos 应用与 PhotosKit 的照片存储模型 (Understand Photo Storage Model on Apple’s Photos App and PhotosKit)
作为 PhotonCam 的开发者，Weichao Deng 在本文中深入探讨了 PhotosKit 的工作原理，并结合其 Android 开发经历，对比了 Android 和 iOS 在照片存储和处理上的差异。文章详细介绍了 PHAsset 和 PHAssetResource 的作用，以及 PhotosKit 如何管理照片的多个版本和辅助数据（如 Apple/ISO Gain Map、Segmentation Matte 等）。此外，文章还为跨平台开发者提供了实用建议，强调在设计和开发照片应用时，需确保跨平台一致性，特别是针对照片存储模型的处理。
让你的应用提供 macOS 系统级服务 (Provide macOS System-wide Services from Your App)
系统级服务允许 macOS 应用将其功能扩展到整个系统，用户可以在任何应用中选择文本并通过上下文菜单或 Services 菜单调用这些服务。Natalia Panferova 以她的工具应用 EncodeDecode 为例，详细讲解了如何通过定义服务提供者类、注册服务并配置 Info.plist 文件，实现系统级的 URL 编码和解码功能。文章还提供了测试和调试建议，如使用 pbs 工具验证服务注册，适合希望在 macOS 应用中集成系统级服务的开发者参考。
Drone-fireworks were amazing indeed )