Fatbobman's Swift Weekly #115
A Sunday Incident
A Sunday Incident
Sunday afternoon, I was preparing Monday’s weekly newsletter as usual. The moment I stood up, my right pinky finger seemed to bump into something, and then it wouldn’t straighten.
Somewhat bizarre—no pain, no swelling, but just couldn’t extend. The ER doctor’s initial assessment was pinky extensor tendon injury. I scheduled further examination for Monday, and surgery will likely be needed for repair.
It was only then that I realized how important this usually low-profile pinky finger is. Now wearing a finger splint, typing has become significantly difficult. Fortunately, it shouldn’t be anything serious, just that I’ll be typing less for a while.
Life is unpredictable; face it with a smile.
Monday Update: After further examination today, they found no fracture requiring reduction, just a simple tendon rupture. This means no surgery needed—just wearing the finger splint for 6 weeks should restore it to normal.
Previous Issue｜Newsletter Archive
📢 Sponsor Fatbobman’s Swift Weekly
Promote your product to Swift & iOS developers across:
- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate
Perfect for developer tools, courses, and services.
Enjoyed this issue? Buy me a coffee ☕️
Recent Recommendations
From YaoYao to Tooboo: watchOS Development Pitfalls and Practical Tips
As the creator of popular watchOS apps YaoYao, Tooboo, and DunDun, Haozes shares high-quality practical experience in watchOS development, covering version compatibility, app wake-up communication, data synchronization, restart recovery, memory leaks, and battery optimization. This article encompasses a complete guide from HealthKit to WCSession, from HKWorkoutSession to TimelineSchedule, providing invaluable reference for developers who are building or planning to build Apple Watch applications.
As a long-time Apple Watch user and Swift blogger, I often marvel at the “mystique” of watchOS development—countless details beyond the documentation, with very few truly in-depth practical articles available online. For this reason, I specially invited Haozes, a leading independent developer in the watchOS space, to share his development insights.
My journey to Swift 6 and Strict Concurrency
A crash that “only appeared on real user devices” forced Irving Popovetsky to migrate an entire production iOS app to Swift 6 + Strict Concurrency. This article comprehensively documents the journey from the initial 76 errors and 238 warnings, through the gradual introduction of @preconcurrency, actor, @MainActor, Sendable, and nonisolated(unsafe), to verification with real devices and Thread Sanitizer. Irving points out that Swift 6’s runtime validates actor isolation the moment a closure is called—even if you use Task { @MainActor in } inside the closure, it may be too late. The article provides clear, reusable patterns for addressing this behavior.
Monitoring app performance with MetricKit
MetricKit is a system-level performance diagnostics framework introduced by Apple in iOS 13, designed to provide developers with app performance and stability data from real user devices. It only works in real device environments, with data sourced from long-term sampling and aggregation by the system in the background, thus more accurately reflecting app behavior in actual usage scenarios.
In this article, Majid Jabrayilov demonstrates how to subscribe to system-level performance data through MXMetricManager, progressively extracting and reporting key metrics from background abnormal exits, CPU/memory resource limits, to crash diagnostics, thereby building a more complete and traceable app performance monitoring dashboard. Majid also specifically reminds readers that MetricKit data is typically aggregated and delivered daily rather than in real-time callbacks, and actual analysis requires understanding the time range covered by each payload in combination with timestamps.
Rebuilding MistKit with Claude Code - From CloudKit Docs to Type-Safe Swift
When Leo Dion rebuilt MistKit, his long-dormant CloudKit server-side library, he discovered that swift-openapi-generator could significantly reduce refactoring complexity: by simply converting CloudKit’s REST documentation into OpenAPI specifications, he could automatically generate large-scale, type-safe Swift client code. To this end, he brought in Claude Code, specifically responsible for the translation work “from Apple documentation to OpenAPI YAML.”
The most valuable aspect of the article isn’t “how much code AI generated,” but rather how Leo uses AI. He didn’t let Claude directly implement MistKit, but positioned it as a “documentation translator and pattern amplifier,” while keeping the truly complex parts requiring engineering judgment and architectural trade-offs under his own control. Rather than having AI directly “write code,” it’s better to have it turn complex problems into generatable, verifiable problems—this is the most valuable lesson from this MistKit rebuilding process.
I Reverse Engineered ChatGPT’s Memory System, and Here’s What I Found!
Through extensive conversation experiments, Manthan Gupta reverse-engineered ChatGPT’s “memory” behavior and found its implementation far simpler than imagined: no vector database, no RAG across historical conversations, but rather composed of four layers of context—one-time injected Session Metadata, explicitly stored long-term user memories, lightweight summaries of recent conversations, and a sliding window of the current session. Manthan believes this design has obvious advantages in performance, latency, and token costs: trading pre-computed summaries and explicit fact injection for “good enough” continuity, rather than expensive full historical retrieval. Manthan also has another study on Claude’s memory system.
When using ChatGPT, I’m often surprised by how much it knows about me. Although I understand this “familiarity” comes from its memory and context mechanisms, this is also one of the important reasons why I’ve long preferred using the official client. Of course, if you’re particularly sensitive about privacy, this capability itself might be exactly the part you’re unwilling to accept.
Swift Configuration 1.0 released
Honza Dvorsky announced the official release of Swift Configuration 1.0 on the Swift official blog. This library provides a unified, type-safe configuration reading abstraction for Swift applications and libraries. The key isn’t about supporting how many configuration formats, but completely separating “how configuration is read” from “where configuration comes from.” This design is particularly important for library authors—libraries can accept configuration without binding to specific sources, thus maintaining good composability across different deployment environments. With the 1.0 release, Swift Configuration’s API has entered a stable phase and is being explored for integration by projects like Vapor and Hummingbird.
At first glance, introducing such an abstraction layer for configuration management seems somewhat “heavyweight,” but once configuration sources are no longer limited to a single file, or when code needs to be reused across different environments and projects, the advantages in structural clarity and extensibility quickly become apparent.
TCA Architecture: A Glorified Antipattern
This is an extremely opinionated long-form article. Lazar Otasevic systematically argues against TCA’s Action enum + Reducer core design from the perspective of functional programming and SwiftUI’s runtime model, considering it a classic antipattern of “encoding behavior as data” that unnecessarily takes away SwiftUI’s inherent state ownership. Unlike many “anti-TCA” discussions that remain at the emotional or preference level, this article provides a complete, runnable alternative approach: treating State as pure data, Logic as stateless implementation details, and exposing behavior through closures (capabilities), thereby maintaining testability and composability while better aligning with SwiftUI’s declarative data flow model.
Considering the period when TCA first emerged, many developers still struggled with
ObservableObject‘s insufficient response granularity, lack of@MainActorandTasktools, and heavy reliance on Combine for asynchronous calls—TCA effectively solved a series of pain points at that time. However, as Swift and SwiftUI continue to evolve, some of TCA’s once-prominent advantages are no longer as obvious, and its composability model still has considerable learning and usage costs for many developers. Nevertheless, TCA remains a development paradigm that many developers and teams have adapted to and love—ultimately, what suits you is what’s best.
Tools
FluidAudio: Local Audio AI Toolkit for Apple Platforms
FluidAudio is a Swift audio AI SDK designed specifically for Apple platforms, providing fully local speech recognition, speaker diarization, voice activity detection, and other features, primarily developed by Brandon Weng and Alex Weng. All inference runs on the Apple Neural Engine (ANE), achieving low-latency, low-power audio processing capabilities.
Core Features:
Fully Local: All models run on-device, no network connection required, fully protecting user privacy
ANE Optimized: Leverages Apple Neural Engine, avoids GPU/MPS usage, reducing CPU usage and power consumption
Open and Transparent: Based on MIT/Apache 2.0 licensed open-source models, available on Hugging Face
Easy Integration: Install via Swift Package Manager, with clean and intuitive API design
Production Ready: Adopted by well-known apps including Voice Ink, Spokenly, Slipbox, and BoltAI
FluidAudio supports automatic speech recognition (Parakeet TDT v3, 25 European languages), speaker diarization (offline/online dual modes), voice activity detection (Silero VAD), and text-to-speech (Beta). On M4 Pro, speech recognition achieves a real-time factor of approximately 190x, processing 1 hour of audio in just 19 seconds.
If you’re developing iOS/macOS applications involving speech processing, FluidAudio is definitely worth trying.
Navigable: Unified SwiftUI Navigation Management
A major pain point in SwiftUI is how to uniformly manage multi-level routing, sheets, full-screen covers, and alerts across different navigation and presentation mechanisms. Navigable, developed by Corey Davis, provides a more centralized and testable solution: it consolidates all navigation behavior into an observable NavigationState as the single source of truth.
Through this approach, Navigable maintains type-safety and modern Swift (@Observable, Swift 6) features while extracting navigation logic from views, supporting complex flows, deep linking, and unit testing. Additionally, it supports both declarative view construction and imperative APIs (like push / pop) for driving state changes, offering more controllability in complex scenarios similar to traditional routing systems.
The library is still in early development, but its implementation approach is worth continued attention.
Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.
周日小插曲
周日下午，我正准备周一的周报。起身的瞬间，右手小指似乎碰到了什么，然后它就伸不直了。
有些诡异——不痛、不肿，但就是无法伸直。急诊医生初步判断是小指伸肌腱损伤，约了周一做进一步检查，很可能需要手术修复。
这才意识到，平时存在感不强的小指，原来如此重要。现在戴着固定指套，打字变得比较困难。好在应该不是什么大问题，只是接下来一段时间会减少打字量。
人生无常，微笑对待。
周一更新：今天进一步检查后，发现没有需要复位的骨折，只是单纯的肌腱断裂。这样就不用手术了，只需要戴指套固定 6 周就基本能恢复了。
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 爱发电，Buy Me a Coffee 支持我的创作。
近期推荐
从 YaoYao 到 Tooboo：watchOS 开发避坑与实战
作为知名 watchOS 应用 YaoYao、Tooboo、DunDun 的作者，Haozes 分享了 watchOS 开发中关于版本兼容、App 唤起通信、数据同步、重启恢复、内存泄露和电量优化等高质量实战经验。这篇文章涵盖了从 HealthKit 到 WCSession、从 HKWorkoutSession 到 TimelineSchedule 的完整开发避坑与性能调优指南，对于正在开发或计划开发 Apple Watch 应用的开发者具有极高参考价值。
作为一个长期的 Apple Watch 用户和 Swift 博主，我常感叹 watchOS 开发的“神秘”——文档之外细节繁多，且网络上真正有深度的实战文章寥寥无几。为此，我特别邀请了 watchOS 领域的头部独立开发者 Haozes，来分享他的开发体会。
Swift 6 严格并发迁移实战 (My journey to Swift 6 and Strict Concurrency)
一次“只在真实用户设备上才会出现”的崩溃，迫使 Irving Popovetsky 将一整个已上线的 iOS 应用迁移到 Swift 6 + Strict Concurrency。这篇文章完整记录了从迁移之初的 76 个 error、238 个 warning 开始，到逐步引入 @preconcurrency、actor、@MainActor、Sendable、nonisolated(unsafe)，再到真机 + Thread Sanitizer 验证的全过程。Irving 指出，Swift 6 的运行时会在闭包被调用的瞬间验证 actor 隔离，哪怕你在闭包内部再 Task { @MainActor in } 也可能为时已晚。文章中对这一行为给出了清晰、可复用的修复模式。
用 MetricKit 监控应用性能 (Monitoring app performance with MetricKit)
MetricKit 是 Apple 在 iOS 13 引入的系统级性能诊断框架，用于向开发者提供来自真实用户设备的应用性能与稳定性数据。它只在真机环境中工作，数据来源于系统在后台长期采样并聚合的结果，因此能够更真实地反映应用在实际使用场景下的行为。
Majid Jabrayilov 在本文中展示了如何通过 MXMetricManager 订阅系统级性能数据，从后台异常退出、CPU / 内存资源限制，到崩溃诊断信息，逐步提取关键指标并上报，从而构建一个更完整、可追溯的应用性能监控面板。Majid 也特别提醒，MetricKit 的数据通常按天聚合下发，而非实时回调，实际分析时需要结合时间戳理解其所覆盖的时间区间。
用 Claude Code 重构 MistKit (Rebuilding MistKit with Claude Code - From CloudKit Docs to Type-Safe Swift)
Leo Dion 在重建自己停更多年的 CloudKit 服务端库 MistKit 时，发现 swift-openapi-generator 能显著降低重构复杂度：只要将 CloudKit 的 REST 文档转化为 OpenAPI 规范，就可以自动生成大规模、类型安全的 Swift 客户端代码。为此，他引入 Claude Code，专门负责完成“从 Apple 文档到 OpenAPI YAML”的翻译工作。
文章最有价值的地方，并不在于“AI 生成了多少代码”，而在于 Leo 如何使用 AI。他并没有让 Claude 直接实现 MistKit，而是将其定位为“文档翻译与模式放大器”，而真正复杂、需要工程判断与架构取舍的部分，始终由作者亲自把控。与其让 AI 直接“写代码”，不如让它把复杂问题变成可生成、可校验的问题——这正是这次 MistKit 重建过程中最值得借鉴的地方。
ChatGPT 记忆系统逆向分析 (I Reverse Engineered ChatGPT’s Memory System, and Here’s What I Found!)
Manthan Gupta 通过大量对话实验，对 ChatGPT 的“记忆”行为进行了逆向分析，发现其实现方式远比想象中简单：没有向量数据库、没有跨历史对话的 RAG，而是由四层上下文共同构成——一次性注入的 Session Metadata、显式存储的长期用户记忆、近期对话的轻量摘要，以及当前会话的滑动窗口。Manthan 认为，这种设计在性能、延迟和 token 成本上的优势非常明显：通过预计算摘要和显式事实注入，换取“足够好”的连续性，而不是昂贵的全量历史检索。Manthan 还有另一篇针对 Claude 记忆系统的研究。
在使用 ChatGPT 的过程中，我时常会对它对我的了解程度感到惊讶。尽管我清楚，这种“熟悉感”来自其记忆与上下文机制，但这也正是我长期偏向使用官方客户端的重要原因之一。当然，如果你对隐私问题格外敏感，那么这种能力本身，可能正是你不愿接受的那一部分。
Swift Configuration 1.0 released
Honza Dvorsky 在 Swift 官方博客中宣布 Swift Configuration 1.0 正式发布。该库为 Swift 应用与库提供了一套统一、类型安全的配置读取抽象，其关键并不在于支持多少配置格式，而是彻底分离「配置如何读取」与「配置来自哪里」。这一设计对库作者尤为重要——库可以接受配置而不绑定具体来源，从而在不同部署环境中保持良好的可组合性。随着 1.0 发布，Swift Configuration 的 API 已进入稳定阶段，并开始被 Vapor、Hummingbird 等项目探索集成。
乍看之下，为配置管理引入这样一个抽象层似乎显得有些“重量级”，但一旦配置来源不再局限于单一文件，或者代码需要在不同环境与项目中复用，其带来的结构清晰度与扩展性优势就会迅速显现。
TCA 架构：一个被美化的反模式？ (TCA Architecture: A Glorified Antipattern)
这是一篇立场极其鲜明的长文。Lazar Otasevic 从函数式编程与 SwiftUI 的运行模型出发，系统性地反对了 TCA 以 Action enum + Reducer 为核心的设计，认为这是一种“将行为编码为数据”的经典反模式，并且不必要地夺走了 SwiftUI 原本应当拥有的状态所有权。与许多停留在情绪或偏好层面的“反 TCA”讨论不同，本文给出了一套完整、可运行的替代思路：将 State 视为纯数据、Logic 视为无状态的实现细节，并通过闭包（capabilities）暴露行为，从而在保持可测试性与可组合性的同时，更贴合 SwiftUI 的声明式数据流模型。
考虑到 TCA 刚出现的时期，很多开发者仍难以应对
ObservableObject响应颗粒度不足、缺乏@MainActor、Task等工具、异步调用高度依赖 Combine 的现实处境，TCA 确实有效解决了当时的一系列痛点。但随着 Swift 与 SwiftUI 的不断演进，TCA 中一些曾经突出的优势已不再明显，而其可组合性模型对不少开发者而言，使用与理解成本也依然不低。即便如此，TCA 仍然是许多开发者和团队已经适应并喜爱的开发范式——归根结底，适合自己的，才是最好的。
工具
FluidAudio: 为 Apple 平台打造的本地化音频 AI 工具包
FluidAudio 是一个专为 Apple 平台设计的 Swift 音频 AI SDK，提供完全本地化的语音识别、说话人分离、语音活动检测等功能，由 Brandon Weng 和 Alex Weng 主导开发。所有推理都在 Apple Neural Engine (ANE) 上运行，实现了低延迟、低功耗的音频处理能力。
核心特性：
完全本地化：所有模型在设备端运行，无需网络连接，充分保护用户隐私
ANE 优化：充分利用 Apple Neural Engine，避免使用 GPU/MPS，降低 CPU 使用率和功耗
开源透明：基于 MIT/Apache 2.0 许可的开源模型，可在 Hugging Face 获取
易于集成：通过 Swift Package Manager 安装，API 设计简洁直观
生产就绪：已被 Voice Ink、Spokenly、Slipbox、BoltAI 等知名应用采用
FluidAudio 支持自动语音识别（Parakeet TDT v3，25 种欧洲语言）、说话人分离（离线/在线双模式）、语音活动检测（Silero VAD）以及文字转语音（Beta）。在 M4 Pro 上，语音识别的实时系数可达约 190x，处理 1 小时音频仅需 19 秒。
如果你正在开发涉及语音处理的 iOS/macOS 应用，FluidAudio 绝对值得尝试。
Navigable: 统一 SwiftUI 导航管理
SwiftUI 中的一大痛点，在于如何将多级路由、sheet、full-screen cover 以及 alert 等不同导航与展示机制统一管理。由 Corey Davis 开发的 Navigable 提供了一种更集中、可测试的解决方案：它将所有导航行为统一收敛到一个可观察的 NavigationState 中，作为唯一的状态来源。
通过这种方式，Navigable 能够在保持 type-safe 与现代 Swift（@Observable、Swift 6） 特性的同时，将导航逻辑从视图中剥离出来，支持复杂流程、深链以及单元测试。同时，它既支持声明式的视图构建，也允许通过命令式 API（如 push / pop）驱动状态变化，在复杂场景下更接近传统路由系统的可控性。
该库仍处在开发早期，但其实现思路值得持续关注。
That’s wild, amigo. I hope your recovery is…swift. 😏 Welcome to the era of your life where you can hurt yourself by “sleeping wrong.” 🫠 [We need an Old Man yells at the cloud emoji.]
Take care! We are still typing a lot even in AI era.