大学毕业快三十年了，同学们大多忙于事业与生活，群里常年冷清。但上周四晚上，一阵久违的热闹突然打破了沉寂。
一位十几年未露面的同学重新加入群聊，说家里遭遇了变故，向大家求助。很快就有人提出质疑——这真的是本人吗？毕竟群里多数人从事法律相关工作，职业敏感度让他们对任何异常格外警觉。
语音通话、视频聊天，一轮轮验证下来，仍有人不放心：“现在 AI 造假太容易了，光凭这些可不够。”直到更多细节被摆上桌面——共同经历、内部昵称、只有我们知道的旧梗——大家才最终确认身份，随即伸出援手，帮助他度过暂时的难关。
严格来说，并不能怪大家变得多疑。在如今一部手机就能“换头”“变声”的时代，“眼见为实”早已不再成立。社交媒体上布满了由 AI 生成的各种离奇情景，人们对“离谱视频”的耐受度不断被拉高：谁家的宠物不会说话、做饭呢？也许哪天真看到 UFO 降落，都不会再令人惊讶——我们对未知的恐惧阈值，正在被悄悄重塑。
随之而来的，是一种新的信息焦虑：过去担心的是获取不及时、不全面；如今担心的是获取的内容是否真实。“可信来源”，正在变成一件稀缺品。
当然，这一切不能算在 AI 头上。AI 本质上只是工具，真正利用它造假、行骗的仍然是人，只是欺骗的方式变了、成本更低了。
在这种背景下，重拾真实与信任，只会变得愈发困难。 或许，最终仍需“魔法打败魔法”：数字签名、可信时间戳、区块链验证……它们未必是完美解法，但至少是值得探索的方向。
从小我母亲就常说：“从善如登，从恶如崩”。
信任亦如此——重建远比摧毁艰难，却也正因如此才显得格外珍贵。
本期赞助
需要在 iPhone 上调试 HTTPS？
试试 Proxyman！这是一款顶级的 macOS 应用，只需点击几下，即可轻松捕获和调试 HTTP(s) 流量。支持 iOS设备和模拟器。
近期推荐
深入 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 的核心功能中使用。你可以直接以如下的方式进行布局:
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 领域长期缺乏成熟工具的空白。