Dangerous but Fortunate — Twice!
My parents-in-law have always been in good health, especially my father-in-law, who had never been hospitalized in his more than eighty years. Yet within a short span of time, they both went through life-threatening moments — fortunately, both ended well.
The first incident involved my mother-in-law. The day we picked her up from the airport, we noticed she looked unwell. She mentioned not having slept well and suspected another episode of kidney stones. Just as we decided to cancel our dinner plans, she suddenly began shaking violently, though her forehead remained cool. When we checked her blood oxygen level, we saw it dropping rapidly — even with immediate oxygen support, it fell as low as 78.
By the time the ambulance arrived (about 40 minutes later), her temperature had risen to 39.8°C, reaching nearly 41°C upon arrival at the hospital. She was in very poor condition. Fortunately, because she had mentioned kidney stone discomfort earlier, the doctors quickly conducted examinations and diagnosed urosepsis — the stone had blocked her ureter, allowing bacteria to multiply rapidly and enter her bloodstream. The doctor told us bluntly that had we arrived any later, the consequences could have been dire. Thinking about how she had just gotten off the plane, we couldn’t help but feel terrified in hindsight — thank goodness the flight wasn’t delayed, thank goodness we had chosen the early morning flight that day. After emergency drainage surgery, her condition improved significantly the next day, and she was discharged after a few days.
Shortly after, it was my father-in-law’s turn to experience his own “dangerous but fortunate” ordeal. While caring for my mother-in-law, he developed a cough accompanied by a mild fever. A CT scan showed only bronchiectasis, but given his age, we insisted he be hospitalized for observation. During a routine ECG, the doctor unexpectedly discovered he had atrial fibrillation, with his heart rate fluctuating dramatically between 130 and 170. Astonishingly, he felt no discomfort whatsoever. He later told us that during his physical examination in May, the doctor had mentioned the arrhythmia, but he hadn’t taken it seriously — nor had he told us. Because of the extremely high heart rate, treatment immediately shifted to controlling his cardiac rhythm. Once again, fortune smiled upon us — after several hours on amiodarone, his heart rate gradually dropped below 80, successfully restoring normal rhythm. Although he remains hospitalized, his condition is stable, and after discharge he’ll only need to continue heart rate control and anticoagulation medication. This fortuitous discovery likely helped him avoid the serious complications that atrial fibrillation can bring.
Two unexpected crises within a single week reminded us of both the fragility of life and the importance of cherishing the present. Fortune often favors those who act promptly and take health warnings seriously. May we all pay more attention to our own and our loved ones’ health — and rely less on luck.
Previous Issue｜Newsletter Archive
📢 Sponsor Fatbobman’s Swift Weekly
Promote your product to Swift & iOS developers across:
- Blog: 70,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
onChange(anyOf:initial:_:)
onChange is a commonly used state observation tool in SwiftUI, allowing developers to execute logic when a specific value changes in a view. However, despite multiple improvements over the years, it still can only observe a single value at a time. To execute the same action when multiple states change, developers must add multiple identical onChange closures. In this article, Matt Comi leverages variadic generics to enable onChange to monitor multiple values simultaneously, creating a more efficient and elegant solution.
ScrollView snapping in SwiftUI
Since iOS 17, developers can control ScrollView scrolling behavior through scrollTargetBehavior, such as snapping by page or by view. In this article, Natalia Panferova explores the API’s usage in detail and shares practical experience along with pitfalls to avoid: view-aligned mode requires each snap target to fit within the visible area; when a single item’s size exceeds the container size, scrolling feels “stuck”; for oversized items, custom ScrollTargetBehavior implementation is needed.
In Mastering SwiftUI Scrolling: Implementing Custom Paging, I also demonstrated how to resolve scroll offset and imprecise page alignment issues in landscape mode through custom ScrollTargetBehavior.
Roadmap for improving the type checker
As a Swift developer, you’re undoubtedly familiar with the dreaded “unable to type-check this expression in reasonable time” error. Why does this compilation error occur? How will Swift reduce its frequency? Swift core team member Slava Pestov provides detailed explanations and improvement directions in this roadmap.
The issue stems from the exponential time complexity of constraint solving. To prevent the compiler from endless backtracking, Swift imposes two limits: a maximum of 1 million disjunction choices and a constraint solver memory cap of 512 MB. Swift 6.2 achieved initial speedups through optimized underlying algorithms, while Swift 6.3’s new disjunction selection algorithm and memory optimizations brought significant improvements: type-checking time for the same test project dropped from 42 seconds to 10 seconds. The Swift team’s goal is to compress “exponential worst-case scenarios” into fewer, more edge-case situations through continuous algorithm and implementation optimization, without sacrificing language expressiveness.
Playing with Sheet (on iOS)
On iOS, Sheet once meant “full-screen takeover”—sliding up from the bottom, blocking everything, waiting for the user to tap “Done.” But that era has passed. Apple has redefined content presentation: under the new design philosophy, Sheet is no longer an interruption but part of the rhythm—it can slide, float, expand, collapse, keeping the interface coherent and breathing. Danny Bolella demonstrates the customizable features of modern Sheet from multiple perspectives and shows through examples how these features transform Sheet from “flow interruption” to “context expansion.”
For the issue of Sheet not automatically adapting to content height, developers can achieve dynamic height adjustment through this technique that measures content height with
GeometryReaderand combines it with.id()refresh.
Optimize Your App’s Speed and Efficiency: Q&A
Anton Gubarenko compiled Q&A content from Apple’s “Optimize your app’s speed and efficiency” event, covering SwiftUI performance (closure capture optimization, Observable usage, @Binding vs let), Liquid Glass containers (GlassEffectContainer best practices), Foundation Models framework (multilingual support, concurrent usage, latency optimization), and Instruments tools (Hitch vs Hang, new Power Profiler), among other key areas.
This Q&A demonstrates Apple’s engineering team’s practical approach to performance tuning: transforming optimization from “black box experience” into “measurable, verifiable engineering processes” through detailed analysis and tool-driven methods.
Workaround: how to silence individual deprecation warnings in Swift
In development, it’s inevitable to use deprecated APIs. When enabling “warnings as errors” (-warnings-as-errors), this creates a compilation dilemma. Unlike Objective-C, which can use #pragma clang diagnostic to disable warnings for specific code sections, Swift still lacks an equivalent mechanism.
Jesse Squires shares a clever solution: define a protocol wrapping the deprecated API, implement it in an extension marked with @available(*, deprecated), then call it by casting to the protocol type. The compiler looks up the method through the protocol witness table, thus “hiding” the deprecation warning. While the approach is somewhat verbose, it’s practical for pure Swift projects that must use legacy APIs.
Deep Dive into Swift Internals: From Binary Optimization to Reverse Engineering
The following articles are quite hardcore, suitable for readers interested in toolchain, runtime, and binary-level details.
static const in header cost: dyld ships with redundant 2KB data copy by Kyle Ye
Reveals the causes and costs of binary bloat through a case study of
static constheader definitions being duplicated across multiple compilation units in dyld, and proposes fixes.Reverse engineer a swift binary by Erk Ekin
Demonstrates how to disassemble Swift executables, locate strings and conditional branches, and achieve “patched” execution through instruction modification and re-signing, using a simple login program.
How do researchers reverse-engineer private frameworks? by Jacob Bartlett
Introduces how to extract Mach-O from Simulator runtime and reconstruct private framework interfaces using MachOSwiftSection, parse Swift metadata structures, and even observe system capability evolution through version diffs.
Tools
Swift Stream IDE - Cross-Platform Swift Development Extension
Swift Stream IDE is a powerful VS Code extension developed by Mikhail Isaev, designed to enable developers to smoothly build Swift projects targeting non-Apple platforms. Based on VS Code’s Dev Containers extension, it fully encapsulates compilers, dependencies, and toolchains in Docker containers, achieving truly consistent and portable cross-platform Swift development experience. Currently, Swift Stream supports multiple project types, including Web (WebAssembly), Server (Vapor/Hummingbird), Android (library development), and Embedded (ESP32-C6, Raspberry Pi, etc.).
In The Swift Android Setup I Always Wanted, Mikhail also demonstrates how to efficiently build Android native libraries by combining Swift Stream IDE, swift-android-sdk, and JNIKit.
The advantages of containerized development include: keeping the host environment clean, ensuring reproducible builds for old projects, supporting consistent cross-platform development experience, and enabling remote development on more powerful machines via SSH.
AnyLanguageModel - Unified LLM Development Paradigm
Many developers may not immediately adopt the Foundation Models framework introduced at WWDC 2025, but most are impressed by its API—this framework significantly simplifies interaction with language models and fully leverages Swift language features.
Mattt‘s AnyLanguageModel implements an API fully compatible with the Foundation Models framework: simply replace import FoundationModels with import AnyLanguageModel, and you can integrate multiple cloud and local model backends (OpenAI, Anthropic, Ollama, llama.cpp, Core ML, MLX, and Foundation Models) without changing upper-layer business code. Additionally, the library leverages Swift 6.1’s Traits feature to selectively include heavy dependencies, significantly reducing binary size and improving build speed.
惊险但幸运，两次！
我的岳父岳母的身体一向很好，尤其是岳父，八十多岁了从未住过院。但在短短的时间里，他们先后经历了两场惊魂时刻——好在结果都十分幸运。
先是岳母。那天我们刚从机场接她回家，发现她脸色不好，自述昨晚没睡好，似乎又有肾结石发作的迹象。正当我们决定取消外出用餐时，她突然开始剧烈发抖，但额头仍是凉的。测量血氧后发现指标在快速下降——即使立即开始吸氧，最低时也掉到了 78。
救护车到达时（约 40 分钟后），体温已升至 39.8℃；送医时更是接近 41℃。人的状态非常差。幸运的是，在此前她提到过肾结石的不适，医生据此快速展开检查，确诊为尿源性脓毒症——结石堵住输尿管，细菌在尿液中迅速繁殖，最终进入血液。 医生直言，若再晚些送来，后果可能不堪设想。想到她刚下飞机，我们也不禁后怕——幸亏航班没有延误，幸亏那天决定乘坐早班机。经过紧急手术引流后，她的状况在第二天便明显好转，数日后顺利出院。
不久之后，又轮到岳父经历一次“惊险但幸运”的考验。 在照顾岳母期间，他出现咳嗽并伴随低热。CT 显示只是支气管扩张，但考虑到年龄，我们坚持让他住院观察。 在例行心电图检查中，医生意外发现他有房颤，心率在 130–170 之间剧烈波动。令人吃惊的是，他本人毫无不适感。事后他说，今年 5 月体检时医生就提醒过有房颤，但他没当回事，也没有告诉我们。 由于心率过快，治疗重心立即转为控制心律。幸运再次眷顾——在使用胺碘酮（Amiodarone）数小时后，心率逐渐恢复至 80 以下，成功复律。如今虽然仍在住院，但情况稳定，只需出院后按医嘱服用控制心率与抗凝药物即可。这次的阴差阳错，也让他在不经意间避免了房颤可能带来的更严重后果。
短短一周内的两次意外，让人既感叹生命的脆弱，也更懂得珍惜当下。幸运往往属于那些及时行动、认真对待健康警示的人。愿我们都能对自己和家人的身体多一分关注，少一分侥幸。
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 爱发电，Buy Me a Coffee 支持我的创作。
近期推荐
让 onChange 同时监听多个值 onChange(anyOf:initial:_:)
onChange 是 SwiftUI 中常用的状态监听工具，开发者可以通过它在视图中针对某个值的变化执行逻辑。不过，尽管该修饰符历经多次改进，它仍然只能同时观察一个值。若要在多个状态变更时执行相同操作，就需要重复添加多个内容相同的 onChange 闭包。在本文中，Matt Comi 借助 variadic generics（可变参数泛型)，让 onChange 能够同时监听多个值，从而构建出一个更高效、更优雅的解决方案。
SwiftUI 中的滚动吸附 (ScrollView snapping in SwiftUI)
从 iOS 17 开始，开发者可以通过 scrollTargetBehavior 控制 ScrollView 的滚动行为，比如按页面吸附或按视图吸附。Natalia Panferova 在这篇文章中详细探讨了该 API 的用法，并分享了实践经验和需要注意的陷阱：视图对齐模式要求每个吸附目标适配可见区域；当单个项目尺寸超过容器大小时，滚动会感觉”卡住”；对于超大项目，需要考虑自定义 ScrollTargetBehavior。
在 精确掌控 SwiftUI 滚动：自定义 Paging 实现 一文中，我也介绍了如何通过自定义 ScrollTargetBehavior 解决横屏模式（Landscape）下滚动偏移、页面对齐不精确的问题。
Swift 类型检查器改进路线图 (Roadmap for improving the type checker)
作为 Swift 开发者，你一定不会对那句 “unable to type-check this expression in reasonable time” 感到陌生。为什么会出现这个编译错误？Swift 又将如何减少这种情况的发生？Swift 核心团队成员 Slava Pestov 在这份路线图中给出了详细的解释与改进方向。
该问题源自约束求解（constraint solving）的指数时间复杂度。为防止编译器陷入无休止的回溯，Swift 设定了两项限制：析取选择次数上限（100 万次） 和 求解器内存上限（512 MB）。Swift 6.2 通过优化底层算法实现了初步提速，而 Swift 6.3 引入的新析取选择算法与内存优化带来了显著改进：同一测试项目的类型检查时间从 42 秒降至 10 秒。Swift 团队的目标是在不牺牲语言表达力的前提下，通过算法与实现层的持续优化，将“指数最坏情况”压缩到更少、更边缘的实际场景中。
iOS Sheet 的现代化演进 (Playing with Sheet (on iOS))
在 iOS 上，Sheet 曾经意味着“全屏接管”——从底部滑出、阻挡一切、等待用户点击“完成”。但如今，这种模式已经过去。Apple 重新定义了内容的呈现方式：在新的设计哲学下，Sheet 不再是中断，而是节奏的一部分——它可以滑动、漂浮、扩展、折叠，让界面保持连贯与呼吸感。Danny Bolella 从多个层面展示了现代 Sheet 的可定制特性，并通过实例演示了这些特性如何让 Sheet 从“流程中断”转变为“上下文扩展”。
针对 Sheet 无法自动适应内容高度的问题，开发者可以通过
GeometryReader测量内容高度并结合.id()刷新的技巧来实现动态高度调整。
iOS 性能优化：Apple 工程师问答精选 (Optimize Your App’s Speed and Efficiency: Q&A)
Anton Gubarenko 整理了 Apple “Optimize your app’s speed and efficiency” 活动中的 Q&A 内容，涵盖 SwiftUI 性能（闭包捕获优化、Observable 使用、@Binding vs let）、Liquid Glass 容器（GlassEffectContainer 的最佳实践）、Foundation Models 框架（多语言支持、并发使用、延迟优化）以及 Instruments 工具（Hitch vs Hang、新增 Power Profiler）等关键领域。
本次 Q&A 展现了 Apple 工程团队在性能调优层面的实践取向：通过细节分析与工具驱动，让优化从“黑盒经验”转变为“可度量、可验证的工程流程”。
Swift 中禁用单个弃用警告的技巧 (Workaround: how to silence individual deprecation warnings in Swift)
开发中难免必须使用一些被软废弃（deprecated）的 API。在开启“警告即错误”（-warnings-as-errors）后，将面临无法编译的窘境。不同于 Objective-C 可以使用 #pragma clang diagnostic 针对特定代码段禁用警告，Swift 至今没有等效机制。
Jesse Squires 分享了一个巧妙的解决方案：定义一个协议包装弃用 API，在扩展中实现时标记为 @available(*, deprecated)，然后通过类型转换为协议类型来调用。编译器会通过协议见证表查找方法，从而“隐藏”弃用警告。虽然方案略显冗长，但对于必须使用遗留 API 的纯 Swift 项目很实用。
深入 Swift 底层：从二进制优化到逆向工程
以下几篇文章都偏硬核，适合关注工具链、运行时与二进制层面细节的读者。
static const in header cost: dyld ships with redundant 2KB data copy by Kyle Ye
通过 dyld 中
static const头文件定义被多处编译单元重复包含的案例，揭示了二进制体积膨胀的成因与代价，并提出修复方案。Reverse engineer a swift binary by Erk Ekin
通过一个简单的登录程序，演示如何反汇编 Swift 可执行文件、定位字符串与条件分支，并通过修改指令和重新签名实现“补丁式”运行。
How do researchers reverse-engineer private frameworks? By Jacob Bartlett
介绍如何借助 MachOSwiftSection 从 Simulator runtime 抽取 Mach-O 并还原私有框架接口，解析 Swift 元数据结构，甚至通过版本 diff 观察系统能力的演进。
工具
Swift Stream IDE - 跨平台 Swift 开发扩展
Swift Stream IDE 是由 Mikhail Isaev 开发的功能强大的 VS Code 扩展，旨在让开发者能够流畅地构建面向非 Apple 平台的 Swift 项目。它基于 VS Code 的 Dev Containers 扩展，将编译器、依赖与工具链完整封装在 Docker 容器中，实现了真正一致、可移植的跨平台 Swift 开发体验。目前，Swift Stream 已支持多种项目类型，包括 Web（WebAssembly）、服务器（Vapor/Hummingbird）、Android（库开发）、嵌入式（ESP32-C6、树莓派等）等多种项目类型。
在 The Swift Android Setup I Always Wanted 一文中，Mikhail 还演示了如何结合 Swift Stream IDE、swift-android-sdk 与 JNIKit，高效构建 Android 原生库。
容器化开发的优势包括：保持宿主机环境整洁、确保旧项目的可编译性、支持跨平台一致的开发体验，以及可通过 SSH 远程连接到更强大的机器进行开发。
AnyLanguageModel - 统一 Swift 大模型开发范式
或许许多开发者不会在第一时间使用 WWDC 2025 上推出的 Foundation Models 框架，但大多数人都对它的 API 印象深刻——这一框架显著简化了与大模型的交互流程，并充分发挥了 Swift 语言特性。
Mattt 开发的 AnyLanguageModel 实现了与 Foundation Models 框架完全兼容的 API：只需将 import FoundationModels 换成 import AnyLanguageModel，就能在不改动上层业务代码的前提下，接入多家云端及本地模型后端（OpenAI、Anthropic、Ollama、llama.cpp、Core ML、MLX 以及 Foundation Models）。此外，该库还利用 Swift 6.1 的 Traits 特性，可按需引入重依赖，从而显著降低二进制体积并提升构建速度。
Metal Lab - 基于 Apple Metal API 生态的中文图形学社区
在中文互联网上，关于 Metal 的教程资源非常稀少，尽管 Apple 官方提供了详尽的文档和示例代码，但这些文档对于国内开发者而言往往语言晦涩、结构复杂，缺乏通俗易懂的入门指导，初学者常常感到难以上手。Metal Lab 提供的教程文档旨在填补这一空白，为中文开发者提供一份系统性、易懂、循序渐进的 Metal 入门资料，帮助他们从零开始掌握 Metal 编程的精髓。无论是游戏开发、图形渲染，还是计算机视觉应用，这都是一份值得收藏的中文资源。
Really glad to hear everything went okay with your family.
A couple of years ago, I had a very similar situation with my dad who had a cardiac arrest while commuting.
Luckily, by astronomical good fortune, he happened to do it at London Bridge station 10 seconds before his train would have left. Which is the only station in London that has paramedics and a defibrillator on site, and so ended up making a full recovery after a scary month in the ICU.