Fatbobman's Swift Weekly #116
Swift, SwiftUI & SwiftData: A Mature 2025
Swift, SwiftUI & SwiftData: A Mature 2025
Over the past few days, I’ve been reflecting on the evolution of Swift, SwiftUI, and SwiftData throughout this year. My overall impression is that while there weren’t many “flashy” surprises, a palpable sense of maturity has quietly emerged.
Undoubtedly, the centerpiece of Swift this year was the continued refinement of the concurrency programming experience. Although the influx of new options and keywords caused its fair share of teething troubles for developers in the short term, after months of debate and practice, the community is finally beginning to consolidate best practices for this new paradigm. I don’t expect the full establishment and widespread adoption of this paradigm to be a simple or swift process. However, in a year or two, the community’s focus will likely shift from concurrency to cross-platform development, marking a brand-new phase for the language.
For SwiftUI, the focus this year was largely centered on adapting to Liquid Glass. Due to initial implementation hurdles at the system level, the visual results were somewhat underwhelming at first. However, since the release of iOS 26.2, both performance and stability have seen significant improvements. To be honest, I am actually quite pleased that SwiftUI didn’t introduce more “revolutionary” features this year. This has given both the framework team and the developers some much-needed breathing room to truly digest the existing framework. At this stage, resolving legacy issues and optimizing performance is far more meaningful than blindly piling on new features.
The trend of “subtle evolution” is most evident in SwiftData. That said, I believe SwiftData’s performance this year is highly commendable—particularly the fact that many improvements and new features were back-ported to earlier OS versions. I only wish it had been in this state when it was first released three years ago. While SwiftData still lacks some key functionalities, it is now more than capable of handling a significant proportion of projects. With this solid foundation, I look forward to its growth in performance and capability over the coming years.
Personally, I am satisfied with the “report card” delivered by the Swift trio in 2025. I wonder, how do you feel about it?
This is the final issue of the year. I want to express my heartfelt gratitude to all of you for your support and readership throughout the year.
Wishing you all a Happy New Year! Happy Coding!
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 ☕️
Event
iOS Conf SG 2026
Next month (January 21–23), iOS Conf SG will take place in Singapore. I’ll be there in person and will be speaking on the topic “Using SwiftUI as a Language”—a talk not just about code, but about a shift in mindset.
If you’ll be nearby or are planning to attend, feel free to come say hi! The organizers have also provided a special discount for my readers: Fatbobman reader-exclusive 10% off link
Recent Recommendations
My Eight Years with CloudKit: From Open Source IceCream to Commercial Apps
I’ve always believed that the so-called Apple ecosystem is shaped by a combination of hardware, software, services, culture, and overall sensibility. Within that ecosystem, CloudKit is undoubtedly a crucial piece. For developers, using CloudKit well not only leads to better user experiences, but also enables innovation at a relatively low cost.
Cai Yue, the creator of IceCream, shares his eight-year journey with CloudKit—from open-sourcing IceCream in 2017 and gaining official recognition from Apple, to applying CloudKit in real-world commercial products such as Music Mate and Setlists. The article takes a deep dive into CloudKit’s core strengths, key limitations, and more advanced usage patterns.
What’s new in Swift: December 2025 Edition
This is a year-end wrap-up article for the Swift community, written by Tim Sneath and Dave Lester. It systematically reviews the major developments across the Swift ecosystem in 2025, spanning language features, platform expansion, and community growth.
The article not only summarizes how Swift 6.2 lowers the barrier to entry for concurrency through more approachable defaults—while continuing to advance C++ interoperability and memory safety—but also highlights sustained investments across Android, WASM, Windows, BSD, embedded systems, and AWS. Together, these efforts reinforce a clear signal: Swift is no longer a language focused solely on Apple platforms.
You may not agree with every change, but in the first year after entering its second decade, Swift has undeniably delivered a solid and substantial body of work.
My PM insisted we switch to SwiftUI for a massive legacy app rewrite. The result is exactly what you’d expect
I came across this post on Reddit a few days ago. The author complains about their PM’s decision to adopt SwiftUI too casually, arguing that it is ill-suited for rewriting a seven-year-old app. I don’t fully agree or disagree with that take—but what really surprised me was the direction of the comments. The overwhelming majority firmly sided with SwiftUI.
Many developers argued that:
SwiftUI itself is already mature enough; the real issues lie in how it’s implemented
Migration should be incremental, not a big-bang rewrite
SwiftUI’s weak spots can be avoided—for example, by keeping UIKit navigation and migrating only the view layer
Multiple large-scale projects (with over 10 years of history) have already completed successful migrations
This discussion highlights a reality I didn’t quite expect: SwiftUI adoption in production environments is far more widespread than many assume, and developer confidence in SwiftUI is clearly established. By the end of 2025, the claim that “SwiftUI isn’t ready for serious work” may no longer hold up.
As a strong advocate of SwiftUI, I both enjoy working with the framework and remain fully aware that it still has a long road ahead. If you’re still unsure whether SwiftUI is worth investing in, you might want to check out an article I wrote last year, “Common Misconceptions About SwiftUI”. Many of the misconceptions discussed there were echoed—and challenged—in this Reddit discussion.
Non-Sendable First Design
With the arrival of the Swift 6 era, many developers have developed a habit: either make types conform to Sendable, or wrap them in @MainActor or an actor. In this article, Matt Massicotte proposes a highly thought-provoking philosophy: “Non-Sendable First Design.”
The key idea lies in rethinking “isolation.” Isolation is, at its core, a constraint. When a type is marked as @MainActor, it effectively loses the freedom to be accessed synchronously outside of UI contexts. By contrast, a non-isolated, non-Sendable plain type can be far more flexible—it can be owned by any actor and accessed synchronously within that context, while also conforming easily to basic protocols like Equatable, without the complexity of crossing isolation boundaries.
With the introduction of NonisolatedNonsendingByDefault in Swift, this “non-Sendable first” approach is no longer awkward or cumbersome. Instead, its advantages are becoming increasingly apparent: clearer semantics and lower architectural overhead achieved with less isolation. While it won’t fit every scenario, in Swift 6 and beyond it’s a “subtractive” design approach well worth serious consideration.
Resolving Swift Packages faster With Registry from Tuist
Traditional Swift Package Manager dependency resolution is based on Git URLs. Xcode needs to clone entire repositories to retrieve version information and source code, which can be extremely time-consuming for projects with many dependencies (such as Firebase). Registry, on the other hand, is an alternative specification defined by Apple: it downloads archived artifacts for specific versions directly via package identifiers (IDs), bypassing the heavy Git operations.
Tuist recently announced that its Swift Package Registry is now open to all developers. The biggest change is that you no longer need to log in or create a Tuist account to use it.
Lee Young-jun tested the feature and found that dependency resolution (installation) time was reduced to about 35% of the original. However, project generation and build phases didn’t see the same gains, and in some cases even became slightly slower. In GitHub Actions, when combined with caching, dependency installation time for subsequent builds dropped from 53 seconds to 11 seconds—showing that the primary benefits are in CI environments.
Overall, Tuist Registry isn’t a “full pipeline accelerator,” but rather a targeted optimization focused on dependency resolution and cache friendliness. If your project has many dependencies and high CI costs, it’s well worth trying.
iOS Timer vs DispatchSourceTimer｜Safe Usage with Finite State Machine & Design Patterns
For many developers, the most frustrating aspect of working with DispatchSourceTimer is its “fragile” state model: even a slight mistake in call order can lead to crashes. In this article, ZhgChgLi proposes an engineering-focused solution to this highly sensitive state management problem. The article carefully outlines five common crash scenarios (such as calling resume repeatedly or releasing a timer while it’s suspended), and demonstrates how to use a finite state machine (FSM) to encapsulate operations, blocking illegal calls at the logic level while ensuring thread safety through a private serial queue.
This is a hands-on case study that guides readers from “writing code” to “designing systems.” It not only explains how to correctly use GCD timers, but also shows how design patterns can turn a “dangerous” low-level API into a clear, safe, and maintainable industrial-grade component. In an era where Swift Concurrency is becoming the norm, understanding—and elegantly wrapping—these low-level GCD tools remains a core skill for senior iOS developers.
Tools
ml-sharp: Turn Photos into 3D Scenes in Seconds
Apple open-sourced SHARP (Sharp Monocular View Synthesis) last week—an AI model capable of converting a single 2D photo into a 3D scene in under one second (model size: 2.8 GB). Compared to previous state-of-the-art models, it improves visual quality by 25–34% and achieves a 1000× speedup.
The community widely believes SHARP could power future spatial photo features. Today, Spatial Scenes in iOS 26 rely on the Neural Engine for depth reconstruction, whereas SHARP uses the more advanced 3D Gaussian Splatting technique, resulting in significantly higher quality.
The model supports CPU, CUDA, and MPS execution, and developers have already successfully run it on M1, M2, and M3 Macs. The output .ply files are compatible with various 3DGS viewers, and Vision Pro users can view the results directly via Metal Splatter (demo).
While Apple may not always stand out in general-purpose language models, its vertically focused AI models—deeply integrated with hardware and driven by clear application scenarios—continue to demonstrate strong competitiveness.
MaterialView: Breaking the Limits of NSVisualEffectView
Oskar Groth (creator of Sensei) has open-sourced MaterialView, a highly customizable material blur view that goes beyond the limitations of NSVisualEffectView. By reverse-engineering the implementation behind Control Center, Oskar achieved full control over blur radius, saturation, brightness, and tint, and documented the process in a detailed technical article.
Unlike system materials, which only allow you to “pick a type,” MaterialView fully parameterizes the blur effect. Developers can precisely control blur radius, saturation, brightness, tint color, and blend modes, while also supporting active / inactive / emphasized / accessibility states. This makes it an excellent fit for sidebars, floating panels, and utility windows where visual consistency is critical.
The library supports both SwiftUI and AppKit, and includes a demo app with real-time parameter tuning to quickly explore different material configurations.
Note: MaterialView relies on some undocumented Core Animation capabilities (such as
CABackdropLayerandCAFilter). While these APIs have been stable for years, there is still a potential risk of change in future macOS releases.
Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.
Swift、SwiftUI 与 SwiftData：走向成熟的 2025
在过去的几天里，我回顾了这一年来 Swift、SwiftUI 以及 SwiftData 的演进。总的感觉是：惊喜虽不算多，但“成熟感”却在不经意间扑面而来。
毋庸置疑，Swift 今年的重头戏在于改善并发编程的体验。尽管新增的选项和关键字在短期内又给开发者带来了不小的困扰，但经过这几个月的讨论与实践，社区已经显现出逐渐总结出新范式实践路径的趋势。我不认为新范式被确立且广泛接受会是一个简单、迅速的过程，但或许再过一两年，开发者对 Swift 的讨论重心将从并发转向跨平台，届时 Swift 也将迈入全新的发展阶段。
今年 SwiftUI 的更新重心大多集中在 Liquid Glass 的适配上。受限于系统初期的实现，显示效果起初并不尽如人意，但在 iOS 26.2 版本发布后，性能与稳定性都有了显著改善。坦率地说，对于今年 SwiftUI 没有引入更多革命性的新功能，我个人是挺高兴的。这让框架团队和开发者都能获得一点喘息之机，去进一步消化这个框架。在现阶段，解决遗留问题、优化性能与稳定性，远比一味堆砌新特性更有意义。
“变化较小”在 SwiftData 身上体现得尤为明显。但我认为 SwiftData 今年的表现尤为值得肯定，特别是许多改进与新功能都向下适配到了更早的系统版本。真希望它在三年前初次发布时，就能具备现在的状态。尽管 SwiftData 目前仍缺失一些关键功能，但对于相当比例的项目而言，它已经足以胜任。有了这个稳固的基础，其未来几年在性能与功能上的提高非常值得期待。
对于 2025 年 Swift 三件套的交出的答卷，我个人是满意的，不知你的感受如何？
这是本年度的最后一期周报，由衷感谢各位一年的陪伴与厚爱。
祝大家新年快乐，Happy Coding!
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 爱发电，Buy Me a Coffee 支持我的创作。
活动
iOS Conf SG 2026
下个月（1 月 21 日 - 23 日），iOS Conf SG 将在新加坡举行。我也将前往现场，并作为嘉宾进行主题为 “Using SwiftUI as a Language” 的演讲——不仅关于代码，更是关于思维方式的转换。
如果你也在附近，或者计划前往，欢迎来现场打招呼！组委会专门为我的读者提供了优惠：Fatbobman 读者专属九折优惠链接
近期推荐
我和 CloudKit 的这八年：从开源 IceCream 到商业应用实战
我一直认为，所谓的苹果生态是由很多的硬件、软件、服务、人文、气质等综合构建起来的。在这其中，CloudKit 无疑是非常重要的一环。而且对于开发者来说，用好 CloudKit 不仅可以给用户更好的体验，也能低成本的为自己的应用带来创新。
IceCream 作者 Cai Yue 分享他与 CloudKit 八年的开发历程：从 2017 年开源 IceCream 并获得 Apple 官方认可，到将 CloudKit 应用于 Music Mate 和 Setlists 等商业项目的实战经验。文章深入探讨了 CloudKit 的核心优势、关键局限以及进阶玩法。
Swift 2025 年度总结 (What’s new in Swift: December 2025 Edition)
这是一篇面向 Swift 社区的年度收官综述文章，由 Tim Sneath 和 Dave Lester 撰写，系统回顾了 2025 年 Swift 生态在语言特性、平台覆盖与社区建设方面的关键进展。
文章不仅总结了 Swift 6.2 在并发模型上通过更温和的默认策略降低使用门槛，同时继续推进 C++ 互操作与内存安全能力；更重要的是，从 Android、WASM、Windows、BSD、嵌入式到 AWS 等方向的持续投入，反复强化了一个清晰信号——Swift 已不再只是围绕 Apple 平台展开的语言。
或许你未必会认同其中的每一项变化，但在迈入第二个十年后的第一个年头里，Swift 依然交出了一份相当扎实的答卷。
关于 SwiftUI 的讨论 (My PM insisted we switch to SwiftUI for a massive legacy app rewrite. The result is exactly what you’d expect)
几天前无意间在 Reddit 上看到的帖子，作者对 PM 轻易选择 SwiftUI 有所抱怨，认为其无法胜任他们一个七年前开发的应用转换。对于这个观点我不置可否，但评论区的走向却出乎意料——绝大多数参与者都坚定地站在了 SwiftUI 的一边。
大量开发者认为：
SwiftUI 本身已经足够成熟，问题出在实施方式上
应该渐进式迁移，而不是一次性重写
避开 SwiftUI 的弱项——比如可以保留 UIKit 导航，只迁移视图层
多个大型项目（10+ 年历史）已成功完成迁移
这个帖子展现了一个出乎我预料的现实：SwiftUI 在实际生产环境中的采用率比我们想象的高得多；开发者社区对 SwiftUI 的信心已经建立。在 2025 年底，“SwiftUI 难堪大任”的论调或许已经站不住脚了。
作为 SwiftUI 框架的推崇者，我既喜欢该框架，也很清楚它仍有很长的路要走。如果你仍在犹豫是否应该在 SwiftUI 上下功夫，或许可以看一下我在去年写的《几个常见的关于 SwiftUI 的误解》——这篇文章讨论的很多误解，恰好在这次 Reddit 讨论中得到了印证。
非 Sendable 优先设计 (Non-Sendable First Design)
随着 Swift 6 时代的到来，开发者逐渐养成了一种惯性：要么让类型符合 Sendable，要么给它套上 @MainActor 或 actor。在这篇文章中，Matt Massicotte 提出了一个极具启发性的哲学：“非 Sendable 优先设计”。
这一思路的关键在于对“隔离（Isolation）”的重新认识：隔离本身是一种约束。当一个类型被标记为 @MainActor，它实际上就失去了在非 UI 环境下进行同步调用的自由度。相比之下，一个非隔离、非 Sendable 的普通类型反而具有更高的通用性——它可以被任意 Actor 持有，并在其内部安全地进行同步访问，同时也更容易遵循 Equatable 等基础协议，而无需处理跨隔离域带来的复杂性。
随着 Swift 引入 NonisolatedNonsendingByDefault，这种“非 Sendable 优先”的设计路径不再像过去那样笨重或别扭，反而逐渐显现出其优势：以更少的隔离、换取更清晰的语义与更低的架构负担。这或许并非适用于所有场景，但在 Swift 6 之后，它已经成为一种值得认真考虑的、符合语言直觉的“减法”方案。
使用 Registry 加速依赖解析 (Resolving Swift Packages faster With Registry from Tuist)
传统的 SPM 依赖解析是基于 Git URL 的，Xcode 需要克隆整个 Git 仓库来获取版本信息和代码，这在依赖较多（如 Firebase）时非常耗时。而 Registry 是苹果定义的另一种规范：通过包的标识符（ID）直接下载特定版本的归档文件，跳过了繁重的 Git 操作。Tuist 最近宣布将其 Swift Package Registry 功能向所有开发者开放，最大的变化是现在无需登录或创建 Tuist 账号即可使用。
Lee Young-jun 实测发现，使用 Registry 后，依赖解析（Installation）时间缩短至原来的约 35%；但项目生成与构建阶段并未获得同等收益，甚至略有回退。在 GitHub Actions 中配合缓存使用时，二次构建的依赖安装时间则从 53s 降至 11s，优势主要体现在 CI 场景。
总体来看，Tuist Registry 并非“全流程加速器”，而是一个专注于依赖解析与缓存友好性的优化点。如果你的项目依赖数量庞大、CI 成本较高，它值得优先尝试。
iOS Timer 与 DispatchSourceTimer 选择与安全封装技巧｜有限状态机防止闪退
很多开发者在处理 DispatchSourceTimer 时，最头疼的就是它那“易碎”的状态：调用顺序稍有不对便会引发闪退。ZhgChgLi 在本文中针对这种极其敏感的状态管理提出了工程化的解决方案。文章详尽列举了导致崩溃的五大常见场景（如重复 resume、suspend 状态下直接释放等），并分享了如何利用有限状态机 (FSM) 封装操作，从逻辑层屏蔽非法调用，同时配合私有串行队列确保多线程环境下的调用安全。
这是一篇引导读者从“写代码”转向“做设计”的实战案例。它不仅讲清了 GCD 定时器的正确使用方式，更展示了如何借助设计模式，将一个“危险”的底层 API，封装为语义清晰、使用安全、可长期维护的工业级组件。在 Swift Concurrency 日益成为主流的今天，理解并优雅地封装这些底层 GCD 工具，依然是高级 iOS 开发者的重要基本功。
工具
ml-sharp：照片秒变 3D 场景
苹果在上周开源了 SHARP (Sharp Monocular View Synthesis)，一个能在不到 1 秒内将单张 2D 照片转换为 3D 场景的 AI 模型（模型大小 2.8 GB）。相比之前的最佳模型，视觉质量提升 25-34%，速度提升 1000 倍。
社区普遍认为 SHARP 可能用于未来版本的空间照片功能。目前 iOS 26 的 Spatial Scenes 使用 Neural Engine 进行深度重建，而 SHARP 采用更先进的 3D Gaussian Splatting 技术，质量显著提升。
模型支持 CPU/CUDA/MPS 运行，已有开发者在 M1/M2/M3 Mac 上成功运行。输出的 .ply 文件兼容各种 3DGS 查看器，Vision Pro 用户可通过 Metal Splatter 直接查看效果。
尽管苹果在通用语言大模型上不如竞争对手惊艳，但在垂直场景的 AI 模型上，凭借硬件深度整合与明确的应用导向，依然展现出强大的竞争力。
MaterialView: 突破 NSVisualEffectView 限制的毛玻璃视图
Oskar Groth (Sensei 作者)开源了 MaterialView，一个能够突破 NSVisualEffectView 限制的高度可定制毛玻璃视图库。通过逆向 Control Center 的实现，Oskar 实现了对模糊半径、饱和度、亮度和色调的完全控制，并撰写了详细的技术文章讲解实现原理。
与系统原生材质只能“选类型”不同，MaterialView 将模糊效果彻底参数化，允许开发者精确控制模糊半径、饱和度、亮度、tint 颜色与混合模式，并支持 active / inactive / emphasized / accessibility 等状态配置。这使得它非常适合用于侧边栏、浮层面板、工具窗口等对视觉一致性要求极高的场景。
该库同时支持 SwiftUI 与 AppKit，并提供了一个可实时调参的 Demo App，方便快速探索不同材质组合的效果。
需要注意的是，它依赖部分未公开的 Core Animation 能力（如
CABackdropLayer、CAFilter等）。尽管这些 API 多年来相当稳定，但仍存在未来系统版本变动的潜在风险。