First Impressions of WWDC 2026: In Line with Expectations, but More Pragmatic

͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­

	Forwarded this email? Subscribe here for more Fatbobman's Swift Weekly #139 First Impressions of WWDC 2026: In Line with Expectations, but More Pragmatic Fatbobman(东坡肘子) Jun 9   READ IN APP   First Impressions of WWDC 2026: In Line with Expectations, but More Pragmatic Read on web → Like 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. reorderable and swipeActions are no longer limited to specific containers. This is not merely an expansion of their applicable scope; it also reflects further integration of the underlying interaction logic. Perhaps the benefits of this integration will become more apparent in next year’s APIs. @State now supports lazy initialization, text selection on iOS has been enhanced, and alert / confirmationDialog now provide Binding<T?> support. These are all welcome improvements, though they do feel like they arrived a little late. AnyNavigationTransition appears in the interface, but there is still no public support for custom transitions. For now, developers can only choose between the system-provided zoom and crossFade transitions. The new DataDetection framework gives Text better content recognition capabilities; toolbars also gain more control. These changes also show Apple’s continued emphasis on using SwiftUI to build macOS apps. Overall, SwiftUI this year does not rely on a single standout API to create surprise. Instead, through a set of additions and integrations, it moves closer to the everyday needs of complex apps. SwiftData Compared with @Query gaining support for section fetches, and ResultsObserver enabling observation of query result changes outside views, I am more interested in @Attribute(.codable). It provides a clearer storage intent and gives developers a way to avoid falling into the black box of composition. Of course, @Attribute(.codable) is not a silver bullet. It is more like a clearly defined escape hatch SwiftData provides for opaque Codable types: suitable for storing external types that you cannot model yourself, but still genuinely need to persist. The cost is that this content cannot participate in SwiftData’s predicate, sort, or migration awareness. Precisely for this reason, its value lies not in being “more powerful,” but in being “more explicit.” 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 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. 📢 View Sponsorship Options Enjoyed this issue? Buy me a coffee ☕️ Original Core Data + Observation: From Property-Level Reactivity to a Freer Mental Model The 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 NSManagedObject precise property-level observation capabilities. This article discusses the motivation behind this feature, how to use it, the implementation approach, engineering challenges, and some of the trade-offs made during development. Recent Recommendations Bringing Goodnotes to the Web with Swift and WebAssembly As 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. Yuta’s iOS Conf 2026 talk, Swift at Scale: Where Performance Really Comes From, is also worth watching. Compared with the official article’s overview of the overall Goodnotes Web architecture, this talk focuses more on a real Swift performance case: the Goodnotes team found that an Update value type used to aggregate partial UI updates had grown to about 6 KB as features accumulated, and it contained many non-trivial members. Even though most updates only used one or two fields, the hot path still paid the cost of copying and reference counting. The team eventually refactored the data structure through a hot-cold split, keeping frequently accessed fields in the main struct while moving infrequent updates into separate storage. This reduced the type size from about 6 KB to around 300 bytes and brought about a 42% improvement in CPU time. Announcing the Networking Workgroup Swift’s networking APIs are not lacking in choices; rather, there are too many choices with overlapping responsibilities. From URLSession and Network.framework on Apple platforms, to SwiftNIO and AsyncHTTPClient in the server-side ecosystem, and further down to lower-level HTTP representation types, developers often have to deal with inconsistent models and migration costs across different platforms and abstraction layers. More importantly, many of these APIs appeared before modern Swift capabilities such as async/await, structured concurrency, actors, and Sendable had matured, making it difficult for them to naturally reflect Swift’s current strengths in concurrency, safety, and cross-platform development. These issues are discussed more systematically in A Vision for Networking in Swift, while the Swift HTTP API Proposal can be seen as an early exploration in this direction. 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 Lists Michael 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. Adapting to the AI era and improving system stability are indeed becoming shared expectations among more Apple developers. By the time you read this issue, WWDC 2026 has already begun. After reading these wish lists and then watching this year’s announcements, I wonder whether everyone has found the answers they were hoping for. Apple-like Around 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. When we expect Apple to improve system stability, developer tools, and platform experience, this article also reminds us that independent developers and app teams can examine their own products through similar standards. Tools MarkdownPDF: A Markdown-to-PDF Engine Written Entirely in Swift MarkdownPDF 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. Goodnotes shows the engineering practice of migrating a large Swift application to the Web, while MarkdownPDF offers another perspective: when the core logic is pure enough and the dependencies are restrained enough, Swift tools themselves can also adapt naturally to the WebAssembly runtime environment. Swift’s move toward the Web is evolving from a proof of concept into an increasingly concrete engineering choice. AdaEngine: A Swift-first Open Source Game Engine AdaEngine 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. Vladislav gives a more complete introduction to the project in Introducing AdaEngine 0.1.0. Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it. Share 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 容器的能力，这无疑是一个遗憾。reorderable 和 swipeActions 不再局限于特定容器，这不只是适用范围的扩大，也体现了底层交互逻辑的进一步整合。或许这些整合带来的收益，会在明年的 API 中呈现得更加明显。 @State 支持惰性初始化，iOS 上的 text selection 得到增强，alert / confirmationDialog 提供了 Binding<T?> 支持，这些都很好，只是感觉来得稍晚了一些。interface 中出现了 AnyNavigationTransition，但目前仍没有开放自定义 transition 的能力，只能在系统预设的 zoom 和 crossFade 中切换。 新的 DataDetection 框架为 Text 提供了更好的内容识别能力；toolbar 获得了更多控制力，也能看出 Apple 对使用 SwiftUI 开发 macOS 应用的重视。整体来看，今年的 SwiftUI 并不是靠某个单点 API 带来惊喜，而是通过一组补齐和整合，让它更接近复杂 App 的日常需求。 SwiftData 相较于 @Query 支持 section fetch，以及 ResultsObserver 提供视图外观察查询结果变化的能力，我更看重 @Attribute(.codable)。它提供了更明确的存储意图，也给了开发者一个避免陷入 composition 黑盒的渠道。 当然，@Attribute(.codable) 并不是银弹。它更像是 SwiftData 为不透明 Codable 类型提供的明确出口：适合存储你无法建模、但又确实需要持久化的外部类型；代价则是这部分内容无法参与 SwiftData 的 predicate、sort 和 migration 感知。正因如此，它的价值不在于“更强”，而在于“更明确”。 不过，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 的支持，赋予 NSManagedObject 属性级的精确观察能力。本文将围绕这一能力的动因、使用方式、实现思路、工程挑战以及开发过程中的一些取舍展开讨论。 近期推荐 用 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，把原本深植于苹果平台的核心能力延展到更多平台。 Yuta 在 iOS Conf 2026 的演讲 Swift at Scale: Where Performance Really Comes From 也很值得观看。相比官方文章对 Goodnotes Web 整体架构的介绍，这场演讲更聚焦一个真实的 Swift 性能案例：Goodnotes 团队发现，一个用于聚合 UI 局部更新的 Update 值类型随着功能增长膨胀到约 6 KB，并包含大量 non-trivial 成员。即使大多数更新只使用一两个字段，热路径中仍要为复制和引用计数成本付费。团队最终通过 hot-cold split 重构数据结构，将高频字段保留在主结构体中，把低频更新移入单独存储，使类型大小从约 6 KB 降到约 300 bytes，并带来约 42% 的 CPU 时间改善。 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 信息。 与 AI 时代的适配和系统稳定性，确实正在成为更多 Apple 开发者的共同期待。看到本期周报时，WWDC 2026 已经开幕，不知道读完这些愿望再看今年的发布会，大家是否找到了心中期待的答案。 Apple-like 在 WWDC 2026 前后，围绕 Apple 未来方向的讨论明显增多。很多人期待 Apple “回到根本”或重新找回过去的状态，但 David Smith 在这篇文章中选择了一个更有建设性的问题：什么才是 Apple-like？作为一名长期的 Apple 平台开发者，他将这种气质总结为几个方向：The Best, and then Better，Excellence for Everyone，以及 Beneficial and Brilliant。也就是持续追求高质量，即使已经领先也不能消耗用户期待；在价格、可访问性和设计上让优秀体验尽可能服务更多人；并且避免用操纵性的方式追逐短期指标，而是用真正有益、令人惊喜的方式解决用户的问题。 当我们期待 Apple 改善系统稳定性、开发工具和平台体验时，这篇文章也提醒我们，独立开发者和应用团队同样可以用类似的标准审视自己的产品。 工具 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 正是这一能力的演示。 Goodnotes 展示的是大型 Swift 应用迁移到 Web 的工程实践，MarkdownPDF 则提供了另一个角度：当核心逻辑足够纯净、依赖足够克制时，Swift 工具本身也可以自然适配到 WebAssembly 运行环境。Swift 走向 Web，正在从概念验证变成越来越具体的工程选择。 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 平台应用，也能进入游戏、互动工具与创意软件开发场景。 Vladislav 在 Introducing AdaEngine 0.1.0 一文中对项目做了更完整的介绍。 Welcome to my blog Fatbobman's Swift Blog( 肘子的Swift记事本 ) Share fatbobman's Swift Weekly   Like Comment Restack   © 2026 fatbobman 548 Market Street PMB 72296, San Francisco, CA 94104 Unsubscribe