Fatbobman's Swift Weekly #139
Fatbobman's Swift Weekly #139First Impressions of WWDC 2026: In Line with Expectations, but More Pragmatic
First Impressions of WWDC 2026: In Line with Expectations, but More PragmaticLike many developers, I cared more this year about improvements in stability and efficiency, and I also deliberately lowered my expectations for “surprising new features.” With that mindset, after quickly going through several topics from the first day of WWDC 2026 that I personally care about, my initial impression of this year’s event is: it was in line with expectations, and quite pragmatic. AI Although Foundation Models was introduced last year, the capabilities it offered at the time were still not compelling enough for many developers. This year’s changes are clearly more practical: the APIs have been further integrated; image input is now supported; developers can choose between on-device models, Private Cloud Compute, or third-party server models depending on the task; and eligible developers can use Apple Foundation Models running on Private Cloud Compute for free. At the same time, the system is also gaining stronger view awareness, better understanding of app context, and the ability to bring users back into apps through App Intents. These improvements significantly increase the practicality and appeal of Foundation Models. It is no longer merely a framework that is “worth trying”; it is beginning to have the foundation needed to enter real product workflows. Unsurprisingly, more developers will likely be willing to experiment with this system this year and gradually incorporate it as one of the core capabilities of their apps. SwiftUI For me, the biggest change in SwiftUI comes from its comprehensive support for document-based apps. It not only adds a large number of new APIs, but also shifts the mental model toward “observable document objects + asynchronous snapshots + dedicated readers / writers.” This is clearly better suited to complex document apps, and it also aligns more closely with the overall evolution of modern Swift around Observation and Concurrency. The sessions also mentioned that SwiftUI continues to optimize layout- and container-related implementations, bringing noticeable performance improvements in some scenarios. This is an improvement developers have urgently needed. However, SwiftUI still does not provide the ability to create custom Lazy containers, which remains a clear disappointment.
The new DataDetection framework gives SwiftData Compared with Of course, However, SwiftData still does not provide cloud syncing for public / shared data, nor have I seen a clearer signal of performance improvements. These issues will continue to limit its adoption. For many developers, SwiftData this year feels more like it is filling key gaps rather than making a leap significant enough to fundamentally change confidence in it. Xcode Over the past six months, my development workflow has basically been Codex App / Claude App + Xcode, with Xcode appearing significantly less often than the former two. After briefly trying Xcode 27, I expect Xcode’s presence in my workflow to increase noticeably. I am especially looking forward to the changes Xcode’s built-in AI workflows may bring in areas such as fine-tuning UI, improving performance, and validating previews. Device Hub is undoubtedly a major surprise. It integrates simulators, physical device management, system state testing, and dynamic size adjustment into a new workflow. Its impact on day-to-day development experience may be more direct than that of many individual APIs. That said, iPhone apps now also support dynamic size adjustment, which will bring new challenges for developers, especially in terms of data and state organization. Adapting to different sizes is not something that can be solved merely by relying on dynamic layout containers. In many scenarios, large and small sizes correspond to very different navigation logic. This year, I probably won’t rush to write articles about the new SwiftUI and SwiftData APIs. Instead of introducing new interfaces one by one, I would rather spend some time systematically digesting these changes and sorting out the implicit logic behind them: how Apple is reorganizing the relationship between SwiftUI, SwiftData, Foundation Models, and Xcode’s AI workflow — and how these changes will ultimately affect the way we build apps. Previous Issue|Newsletter Archive 📢 Sponsor Fatbobman’s Swift WeeklyPromote your product to Swift & iOS developers across: - Blog: 50,000+ monthly visitors Perfect for developer tools, courses, and services. Enjoyed this issue? Buy me a coffee ☕️ OriginalCore Data + Observation: From Property-Level Reactivity to a Freer Mental ModelThe introduction of the Observation framework refined SwiftUI’s state-driven updates from object-level observation to property-level observation, significantly reducing many unnecessary refreshes caused by coarse-grained observation. More importantly, it makes the declarative logic of state management feel natural again: a view only needs to read the properties it truly depends on, and the framework can establish the corresponding reactive relationships from there. To bring the conveniences of modern Swift features to Core Data, a long-standing persistence framework, I recently explored and implemented Observation support in Core Data Evolution (CDE), giving Recent RecommendationsBringing Goodnotes to the Web with Swift and WebAssemblyAs a well-known note-taking app in the Apple ecosystem, Goodnotes did not choose to completely rewrite its product when moving to the Web. Instead, it brought years of accumulated Swift code into the browser environment through WebAssembly. In this article, Yuta Saito explains how Goodnotes maintains the same ink rendering, document synchronization, CRDT-based conflict resolution, search indexing, and interaction experience on the Web as in the native app. The Swift codebase for Goodnotes Web is about 2.2 million lines of code, of which 1.47 million lines are shared code; the final generated WebAssembly binary is about 50 MB, compressed to around 12 MB with Brotli. The significance of this article is not merely that it shows Swift can run on the Web, but that it presents how a real, large-scale Swift application can use WebAssembly to extend core capabilities originally deeply rooted in Apple platforms to more platforms.
Announcing the Networking WorkgroupSwift’s networking APIs are not lacking in choices; rather, there are too many choices with overlapping responsibilities. From The official establishment of the Networking Workgroup sends an important signal: the Swift ecosystem is beginning to treat networking as cross-platform infrastructure that requires long-term governance, rather than simply allowing individual frameworks and packages to evolve independently within their own domains. The goal of the workgroup is not to simply replace existing solutions, but to promote clearer layering, more consistent types, better interoperability, and stronger observability, so that Swift can have a more unified, modern, and sustainable networking foundation across Apple platforms, server-side development, CLI tools, WebAssembly, Android, Windows, and even Embedded Swift. WWDC 2026 Wish ListsMichael Tsai collected wish lists from several Apple developers ahead of WWDC 2026. Similar to the expectations I shared in the previous issue of the weekly newsletter, most developers are calling for a Snow Leopard-style quality-focused release: rethinking the usability of Liquid Glass on the Mac, reducing instability at the system and framework levels, and fixing long-standing issues that affect daily development, such as iCloud sync, Spotlight, System Settings, error messages, SwiftUI, Xcode, Simulator, indexing, and previews. Many developers also hope that this year will not introduce another wave of “busywork” caused by adapting to new designs, new frameworks, or new review requirements, but instead give the existing platforms more time for refinement. Another clear theme is how Apple’s developer tools should evolve in the age of AI agents. Several authors mention that they hope Apple will provide more official Agent Skills, MCP support, CLI tools, and automation interfaces, allowing AI to more reliably read documentation, operate Xcode, manage App Store Connect, modify project settings, run builds, control Simulator, and even understand UI hierarchies in a more structured way, rather than relying on screenshots or fragile Accessibility information.
Apple-likeAround WWDC 2026, discussions about Apple’s future direction have become noticeably more frequent. Many people expect Apple to “return to its roots” or rediscover its former state, but in this article, David Smith chooses a more constructive question: what does it mean to be Apple-like? As a long-time Apple platform developer, he summarizes this quality into several directions: The Best, and then Better; Excellence for Everyone; and Beneficial and Brilliant. In other words, continuously pursuing high quality, and not spending down user expectations even after getting ahead; making excellent experiences available to as many people as possible through pricing, accessibility, and design; and avoiding manipulative ways of chasing short-term metrics, instead solving users’ problems in ways that are genuinely beneficial and delightful.
ToolsMarkdownPDF: A Markdown-to-PDF Engine Written Entirely in SwiftMarkdownPDF is an open-source Markdown-to-PDF engine written entirely in Swift by Mihaela Mihaljević. It does not depend on platform or system capabilities such as PDFKit, CoreGraphics, WebKit, Chromium, LaTeX, or C-based PDF/Markdown libraries. Markdown parsing, layout, and PDF serialization are all implemented in Swift. Precisely because its core is pure and its dependencies are restrained, the project has strong cross-platform potential. It can target WebAssembly/WASI and generate PDFs from Markdown locally in the browser. The Playground provided by the author demonstrates this capability.
AdaEngine: A Swift-first Open Source Game EngineAdaEngine is an open-source Swift-first game engine and application framework created by Vladislav Prusakov, which recently released its first public milestone, 0.1.0. The project is designed for cross-platform development. Apple platforms are currently the most mature, while support for Windows, Linux, Android, and WebAssembly/WebGPU is also being developed. With a data-driven ECS at its core, AdaEngine combines Swift macros, a plugin-based architecture, SwiftUI-like AdaUI, asset hot reloading, a scene system, 2D physics, audio, input, and Metal / WebGPU rendering backends. It aims to let Swift serve not only Apple platform app development, but also games, interactive tools, and creative software.
Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it. WWDC 2026 初印象:符合预期,但更务实和很多开发者一样,我今年更看重稳定性与效率方面的改善,也主动降低了对“惊喜型新功能”的期待。带着这样的预期,快速浏览了 WWDC 2026 第一天中几个我比较关心的主题后,本届活动给我的初步印象是:符合预期,而且相当务实。 AI 尽管 Foundation Models 在去年已经推出,但当时提供的能力,对很多开发者来说仍不足以构成足够强的吸引力。今年的变化则明显更务实:API 进一步整合,支持图像输入,可以根据任务选择设备端模型、私有云计算或第三方服务器模型;满足条件的开发者还可以免费使用运行在私有云计算上的 Apple 基础模型。与此同时,系统也开始具备更强的视图感知、App 上下文理解,以及通过 App Intents 将用户重新带回应用的能力。 这些改进大幅提升了 Foundation Models 的实用性和吸引力。它不再只是一个“可以试试”的框架,而是开始具备进入真实产品流程的基础。不出意外,今年会有更多开发者愿意尝试这套系统,并逐步将其纳入应用的核心能力之一。 SwiftUI 对我来说,SwiftUI 最大的变化来自对文档类应用的全面支持。它不仅增加了大量新 API,也将心智模型调整为“可观察文档对象 + 异步快照 + 专用 reader / writer”。这显然更适合复杂文档 App,也更符合现代 Swift 在 Observation 和 Concurrency 方向上的整体演进。 Session 中也提到,SwiftUI 在布局与容器相关实现上继续优化,部分场景下的性能会有明显提升。这是开发者迫切需要的改进。不过,SwiftUI 仍未提供自定义 Lazy 容器的能力,这无疑是一个遗憾。
新的 DataDetection 框架为 SwiftData 相较于 当然, 不过,SwiftData 仍没有提供 public / shared 数据的云端同步能力,也没有看到更明确的性能改善信号。这些问题仍会限制它的采纳率。对许多开发者来说,SwiftData 今年更像是在补齐关键缺口,而不是完成一次足以改变信心的跃迁。 Xcode 过去半年中,我的开发模式基本是 Codex App / Claude App + Xcode,其中 Xcode 的出场时间明显少于前两者。在简单使用 Xcode 27 后,我预计接下来它的出场时间会明显增加。我尤其期待在 UI 精细调整、性能改善、预览验证等方面,Xcode 内置 AI 流程能带来的变化。 Device Hub 无疑是一个巨大惊喜。它将模拟器、实体设备管理、系统状态测试和动态尺寸调整整合到一个新的工作流中,这对日常开发体验的影响可能比很多单个 API 更直接。不过,iPhone 应用也开始支持动态尺寸调整,这会给开发者带来新的挑战,尤其是在数据和状态组织层面。针对不同尺寸的适配,并不是只靠动态布局容器就能解决的。很多场景下,大尺寸和小尺寸对应的导航逻辑会有很大差异。 今年我应该不会第一时间围绕 SwiftUI、SwiftData 的新 API 写文章。相比逐条介绍新增接口,我更想花一些时间系统消化这些变化,梳理它们背后的隐含逻辑:Apple 正在怎样重新组织 SwiftUI、SwiftData、Foundation Models 与 Xcode AI 工作流之间的关系,以及这些变化最终会如何影响我们构建 App 的方式。 如果您发现这份周报或我的博客对您有所帮助,可以考虑通过 Buy Me a Coffee 支持我的创作。 原创Core Data + Observation:从属性级响应到心智解放Observation 框架的推出,让 SwiftUI 的状态响应从对象级进一步细化到属性级,显著缓解了许多由粗粒度观察带来的无效刷新问题。更重要的是,它让状态管理的声明式逻辑重新变得自然:视图只需要读取自己真正依赖的属性,框架便能据此建立响应关系。为了让 Core Data 这个老牌持久化框架也能享受到现代 Swift 特性的便利,我近期在 Core Data Evolution(CDE)中探索并实现了对 Observation 的支持,赋予 近期推荐用 Swift 和 WebAssembly 把 Goodnotes 带到 Web (Bringing Goodnotes to the web with Swift and WebAssembly)作为苹果生态中著名的笔记应用,Goodnotes 在走向 Web 平台时,并没有选择完全重写,而是把多年积累的 Swift 代码通过 WebAssembly 带到浏览器环境里。Yuta Saito 在本文中介绍了 Goodnotes 如何在 Web 端保持与原生 App 一致的墨迹渲染、文档同步、CRDT 冲突处理、搜索索引与交互体验。Goodnotes Web 的 Swift 代码规模约 220 万行,其中 147 万行是共享代码;最终生成的 WebAssembly 二进制约 50 MB,经 Brotli 压缩后约 12 MB。这篇文章的意义不只是展示 Swift 可以运行在 Web 上,而是呈现了一个真实的大型 Swift 应用如何借助 WebAssembly,把原本深植于苹果平台的核心能力延展到更多平台。
Swift 官方成立网络工作组 (Announcing the Networking Workgroup)Swift 现在的网络 API 并不是缺少选择,而是选择过多且存在重叠:从 Apple 平台上的 URLSession、Network.framework,到服务端生态中的 SwiftNIO、AsyncHTTPClient,再到更底层的 HTTP 表示类型,开发者在不同平台、不同抽象层之间往往需要面对不一致的模型和迁移成本。更重要的是,很多 API 出现于 async/await、structured concurrency、actors、Sendable 等现代 Swift 能力成熟之前,因此很难自然地体现今天 Swift 在并发、安全性和跨平台方面的语言优势。这些问题在 A Vision for Networking in Swift 中有更系统的阐述,而 Swift HTTP API Proposal 则可以看作是对这一方向的早期探索。 本次 Swift 官方成立 Networking Workgroup,释放了一个很重要的信号:Swift 生态开始把网络能力作为一项需要长期治理的跨平台基础设施来推进,而不只是让各个框架和包在各自场景中独立演进。工作组的目标不是简单替代现有方案,而是推动更清晰的分层、更一致的类型、更好的互操作性和可观测性,让 Swift 在 Apple 平台、服务端、CLI、WebAssembly、Android、Windows 乃至 Embedded Swift 等场景中,都能拥有更统一、现代且可持续的网络基础设施。 WWDC 26 愿望单汇总 (WWDC 2026 Wish Lists)Michael Tsai 汇总了多位 Apple 开发者在 WWDC 2026 前的愿望清单。和我在 上一期周报 中的期许类似,大多开发者在呼吁一次偏向 Snow Leopard 式的质量修复:重新审视 Liquid Glass 在 Mac 上的可用性,减少系统和框架层面的不稳定,修复 iCloud 同步、Spotlight、系统设置、错误提示、SwiftUI、Xcode、Simulator、索引和预览等长期影响日常开发体验的问题。也有不少开发者希望今年不要再引入大量为了适配新设计、新框架或新审核要求而产生的“忙碌工作”,而是给现有平台更多打磨时间。 另一个明显主题是 AI Agent 时代下的 Apple 开发工具应该如何演进。多位作者都提到,希望 Apple 提供更官方的 Agent Skills、MCP、CLI 和可自动化接口,让 AI 能更可靠地读取文档、操作 Xcode、管理 App Store Connect、修改项目配置、运行构建、控制 Simulator,甚至以更结构化的方式理解 UI 层级,而不是依赖截图或脆弱的 Accessibility 信息。
Apple-like在 WWDC 2026 前后,围绕 Apple 未来方向的讨论明显增多。很多人期待 Apple “回到根本”或重新找回过去的状态,但 David Smith 在这篇文章中选择了一个更有建设性的问题:什么才是 Apple-like?作为一名长期的 Apple 平台开发者,他将这种气质总结为几个方向:The Best, and then Better,Excellence for Everyone,以及 Beneficial and Brilliant。也就是持续追求高质量,即使已经领先也不能消耗用户期待;在价格、可访问性和设计上让优秀体验尽可能服务更多人;并且避免用操纵性的方式追逐短期指标,而是用真正有益、令人惊喜的方式解决用户的问题。
工具MarkdownPDF:纯 Swift 编写的 Markdown 转 PDF 引擎MarkdownPDF 是 Mihaela Mihaljević 开源的纯 Swift Markdown 转 PDF 引擎。它不依赖 PDFKit、CoreGraphics、WebKit、Chromium、LaTeX、C PDF/Markdown 库等平台或系统能力,Markdown 解析、排版与 PDF 序列化都在 Swift 内完成。正因为核心足够纯净、依赖足够克制,项目具备良好的跨平台潜力,可以适配到 WebAssembly/WASI 运行目标,并在浏览器本地完成 Markdown 到 PDF 的生成。作者提供的 Playground 正是这一能力的演示。
AdaEngine:Swift-first 开源游戏引擎AdaEngine 是 Vladislav Prusakov 推出的开源 Swift-first 游戏引擎与应用框架,近期发布了第一个公开里程碑 0.1.0。项目面向跨平台而设计,目前 Apple 平台最成熟,并正在推进 Windows、Linux、Android 与 WebAssembly/WebGPU 等平台支持。 它以 data-driven ECS 为核心,结合 Swift 宏、插件化架构、类 SwiftUI 的 AdaUI、资产热重载、场景系统、2D 物理、音频、输入,以及 Metal / WebGPU 渲染后端等能力,试图让 Swift 不只服务于 Apple 平台应用,也能进入游戏、互动工具与创意软件开发场景。
Welcome to my blog Fatbobman's Swift Blog( 肘子的Swift记事本 )
|
