毕业 30 年同学群：一场 AI 引发的"真假难辨"危机
大学毕业快三十年了，同学们大多忙于事业与生活，群里常年冷清。但上周四晚上，一阵久违的热闹突然打破了沉寂。
一位十几年未露面的同学重新加入群聊，说家里遭遇了变故，向大家求助。很快就有人提出质疑------这真的是本人吗？毕竟群里多数人从事法律相关工作，职业敏感度让他们对任何异常格外警觉。
语音通话、视频聊天，一轮轮验证下来，仍有人不放心："现在 AI 造假太容易了，光凭这些可不够。"直到更多细节被摆上桌面------共同经历、内部昵称、只有我们知道的旧梗------大家才最终确认身份，随即伸出援手，帮助他度过暂时的难关。
严格来说，并不能怪大家变得多疑。在如今一部手机就能"换头""变声"的时代，"眼见为实"早已不再成立。社交媒体上布满了由 AI 生成的各种离奇情景，人们对"离谱视频"的耐受度不断被拉高：谁家的宠物不会说话、做饭呢？也许哪天真看到 UFO 降落，都不会再令人惊讶------我们对未知的恐惧阈值，正在被悄悄重塑。
随之而来的，是一种新的信息焦虑：过去担心的是获取不及时、不全面；如今担心的是获取的内容是否真实。"可信来源"，正在变成一件稀缺品。
当然，这一切不能算在 AI 头上。AI 本质上只是工具，真正利用它造假、行骗的仍然是人，只是欺骗的方式变了、成本更低了。
在这种背景下，重拾真实与信任，只会变得愈发困难。 或许，最终仍需"魔法打败魔法"：数字签名、可信时间戳、区块链验证......它们未必是完美解法，但至少是值得探索的方向。
从小我母亲就常说："从善如登，从恶如崩"。
信任亦如此------重建远比摧毁艰难，却也正因如此才显得格外珍贵。
🚀 《肘子的 Swift 周报》
每周为你精选最值得关注的 Swift、SwiftUI 技术动态
- 📮 立即订阅 | weekly.fatbobman.com 获取完整内容
- 👥 加入社区 | Discord 与 2000+ 开发者交流
- 📚 深度教程 | fatbobman.com 探索 200+ 原创文章
近期推荐
深入 iMessage 底层：一个 Agent 是如何诞生的
作为 Apple 生态的开发者，我们常常会面对一个微妙的悖论：系统本身具备强大的能力，但这些能力并不一定以公开 API 的形式向开发者开放。iMessage 正是其中的典型 ------ 它深度融入 iOS 与 macOS，是用户日常沟通的核心载体，却始终没有提供可供开发者使用的自动化接口。imessage-kit 的作者 LingJueYa，分享他在构建这一工具时的探索路径。但其核心挑战几乎都来自 Apple 平台本身：解析以 2001 为纪元的时间戳、从二进制 plist 中恢复 NSAttributedString 内容、在 macOS 的沙盒体系下安全地读取资源、以及与 AppleScript 这种历史悠久的自动化机制打交道。
SwiftUI 已死? UIKit 的回归之路 (2025: The Year SwiftUI Died)
Jacob Bartlett 的这篇文章标题颇具挑衅意味，他提出了一个值得讨论的观点：2025 年也许是 SwiftUI 的拐点，而不是它的巅峰。核心论点在于，苹果将 @Observable 宏和 updateProperties() 方法引入 UIKit，使其具备了现代化的状态管理能力；同时，AI 辅助编程工具的成熟极大降低了编写 UIKit 代码的成本（而 AI 对 SwiftUI 这种声明式范式的理解仍显不足）。
苹果对 SwiftUI 的长期投入不会动摇，尤其考虑到它在多端适配上的天然优势。与此同时，AI 的普及也让许多以 SwiftUI 入门的开发者更容易使用 UIKit 来补齐性能或能力上的不足。选择不一定要非此即彼，可以将两者结合起来用得更好。 这样更好吧
UIKit 中的视图自动刷新 (Automatic property observation in UIKit with @Observable)
UIKit 在 iOS 26 中正式引入了对 Swift Observation 的原生支持。当你在 updateProperties()中读取 @Observable 对象的属性时，UIKit 会自动追踪这些依赖关系，并在数据变化时按需刷新对应视图。Natalia Panferova 通过一个混合 UIKit + SwiftUI 的实际案例展示了这一特性在跨框架数据共享时的便利性。文章还介绍了 iOS 18 的向下兼容方案：在 Info.plist 中添加 UIObservationTrackingEnabled 键，并将更新逻辑放在 viewWillLayoutSubviews() 中即可实现相同效果。
SwiftData 对 AttributedString 的原生支持 (How SwiftData Represents AttributedString in Core Data Storage)
尽管 AttributedString 本身符合 Codable，但过去开发者并不能直接在 SwiftData 模型中将其作为属性使用。这一限制终于在 iOS 26 中被解除 ------ 苹果显然为它开了一条"特别通道"，如今它已经可以像 Int、String 这样的基础类型一样直接存储了。DataScout for SwiftData（SwiftData 数据库分析应用）的作者 Oleksii Oliinyk 在维护工具时遭遇了相关的崩溃问题，并顺势深入分析了其背后的实现机制。
SwiftData 允许开发者将符合 Codable 协议的类型作为模型属性，这本身是一项十分强大的能力。但它的底层处理方式可能与许多人预想的并不相同。我在《在 SwiftData 模型中使用 Codable 和枚举的注意事项》中对 SwiftData 的 Codable 转换逻辑与潜在陷阱做了更系统的介绍。此外，如果你需要在 iOS 26 之前保存 AttributedString，可以参考苹果开发者论坛上的这个帖子。
AnyLanguageModel:统一 Apple 平台的 LLM 接口 (Introducing AnyLanguageModel: One API for Local and Remote LLMs on Apple Platforms)
AnyLanguageModel 是由 Mattt 开发的统一 Swift 大模型接口库，我们已在第 109 期周报中介绍过其核心理念。该库以 Foundation Models 的 API 设计为基础，在保持开发者熟悉的使用方式的同时，统一支持多种模型提供方，包括本地模型（Core ML、MLX、llama.cpp、Ollama）以及云端模型（OpenAI、Anthropic、Google Gemini 等），大幅降低了跨 API、跨运行方式所带来的集成负担，也让探索开源模型变得更容易。
在这篇文章中，Mattt 进一步介绍了 AnyLanguageModel 的设计思路、跨后端的能力抽象及 Swift 6.1 package traits 在控制依赖体积中的作用。值得一提的是，尽管苹果当前尚未在 Foundation Models 中提供图像输入能力，AnyLanguageModel 已为 Claude 等模型补上这一功能，使视觉-语言场景也能在 Apple 平台上顺利落地。
Approachable Concurrency 与 MainActor by Default
无论最终走向如何，Swift 6.2 中引入的 Approachable Concurrency 注定会在 Swift 发展史上留下浓重的一笔。它在某些场景下显著降低了并发编程的心智负担，但也让不少开发者感到"越解释越困惑"。
- 在 Approachable Concurrency in Swift 6.2: A Clear Guide 一文中，Antoine van der Lee 中对相关提案和新行为进行了系统梳理。
- Matt Massicotte 在对这些功能进行了详尽研究和分享后，他在最新文章 MainActor by Default 中强调：至少在现阶段，他不会在项目中启用 Default actor isolation = MainActor，因为"理解为何需要 MainActor，要比理解为何删除它更容易"。
- 不过有一点已经十分明确：MainActor by Default 与嵌入式平台非常契合。在 Embedded Swift Improvements Coming in Swift 6.3 一文中，Doug Gregor 和 Rauhul Varma 则进一步展示了 Swift 6.3 在嵌入式平台上的改进方向与动机。
构建可扩展的白标 iOS 应用 (How to Build Scalable White-Label iOS Apps: From Multi-Target to Modular Architecture)
白标产品（White-Label）指的是一个架构灵活、可在不同客户之间复用的通用 App 框架，能够按需更换品牌皮肤与功能配置（例如通用的订餐 App 模板）。Pawel Kozielecki 在这篇长文中系统梳理了 iOS White-Label 应用的演进路线，将其划分为三个阶段：基础品牌定制、自定义 UI/UX，以及完全模块化。在此基础上，他对比了三种常见实现策略------多 Target、资源复制、模块化架构，并指出随着客户数量与差异化需求增长，真正能够长期扩展、避免维护失控的方案只有模块化（Modular Architecture）。文章还结合大量实战细节，讨论了审核、签名、资源与配置分层、测试与 CI 等白标项目在规模化过程中的关键挑战。
工具
QuickLayout: 声明式 UIKit 布局库
既然 UIKit 已经可以无缝集成 Observation 了，那么以 SwiftUI 风格编写布局代码也就不足为奇了。由 Constantine Fry 开发的 QuickLayout 便提供了这样的能力，其已被 Meta 在 Instagram 的核心功能中使用。你可以直接以如下的方式进行布局:
swift
import QuickLayout
@QuickLayout
class MyCellView: UIView {
let titleLabel = UILabel()
let subtitleLabel = UILabel()
var body: Layout {
HStack {
VStack(alignment: .leading) {
titleLabel
Spacer(4)
subtitleLabel
}
Spacer()
}
.padding(.horizontal, 16)
.padding(.vertical, 8)
}
}UIKit 和 SwiftUI 从来不是对立面，而是两套可互相借鉴的 UI 思维模型。现阶段 SwiftUI 的优势在于抽象与一致性，而高性能、精细控制、工具链支持等仍是 UIKit 的特长。
SettingsKit
几乎所有应用都需要设置界面，虽然编写难度不高，但当选项不断增加时，维护成本也会随之上升。Aether 开发的 SettingsKit 正是为此而生。它让 SwiftUI 开发者可以快速构建一个可扩展、样式统一、并带有搜索能力的设置界面，并内置分组、卡片、侧栏等多种风格，适用于中大型设置模块的搭建。
KurrentDB-Swift
Kurrent（原 EventStoreDB）是一款专门用于事件存储的数据库，它不仅保存系统的最新状态，还能完整记录每一次变化的历史，非常适用于金融、物流、零售、电商、SaaS 等需要强可追溯性的场景。作为 KurrentDB 的 Swift 客户端库，由 Grady Zhuo 开发的 KurrentDB-Swift 支持 Swift 6、async/await 流式订阅与事件读取，补上了 Swift 生态在 Event Sourcing 领域长期缺乏成熟工具的空白。
往期内容
- Homebrew 5.0：并行加速、MCP 加持，与 Intel 的最后倒计时 - #111
- Skip Fuse现在对独立开发者免费！- #110
- 惊险但幸运，两次！ - #109
- Swift 官方发布 Android SDK - #108
💝 支持与反馈
如果本期周报对你有帮助，请：
- 👍 点赞 - 让更多开发者看到
- 💬 评论 - 分享你的看法或问题
- 🔄 转发 - 帮助同行共同成长
🚀 拓展 Swift 视野
- 📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察
- 👥 开发者社区 | Discord 实时交流开发经验
- 📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践