Fatbobman's Swift Weekly #137
From Community Guidepost to Ecosystem Cornerstone: Dave Verwer’s New Chapter
From Community Guidepost to Ecosystem Cornerstone: Dave Verwer’s New Chapter
In issue 751 of iOS Dev Weekly, Dave Verwer announced that the newsletter, which has been running for nearly 15 years, will be handed over to a new team, while he will dedicate himself full-time to Swift Package Index. My own blog gained early attention thanks in part to recommendations from iOS Dev Weekly, and my commitment to writing a commentary for each issue of my newsletter was also greatly inspired by Dave Verwer. For many Apple platform developers, iOS Dev Weekly has long been more than a collection of links. It has been both a guidepost for the community and a long-term companion.
Rather than viewing this as “Dave leaving iOS Dev Weekly”, a phrase that inevitably carries a sense of farewell, I prefer to see it as a shift in focus: from curating the information flow of the Swift community to building infrastructure for the Swift ecosystem.
Swift Package Index was originally created by Dave Verwer and Sven A. Schmidt as the successor to, and a rewrite of, SwiftPM Library. When it first appeared, it was easy to understand it simply as a “website for finding Swift packages.” But after several years of development, SPI has clearly grown far beyond the scope of an ordinary index site. It not only records basic package information, but also uses real builds to verify compatibility across Swift versions and platforms, hosts DocC documentation, displays maintenance status, dependency relationships, licenses, tests, and package scores, and, through projects such as Ready for Swift 6, observes how the broader package ecosystem migrates toward new language features.
These capabilities may seem scattered, but in essence they all point to the same goal: making the Swift package ecosystem easier to evaluate, compare, and trust. For individual developers, choosing a dependency becomes a little less like opening a “blind box”. For teams, it becomes easier to assess risks before introducing third-party libraries. For package authors, SPI provides a public window for showcasing project health and documentation quality. A mature package ecosystem cannot exist on Package.swift alone. It also needs visible compatibility, continuous documentation, stable build verification, and a trust mechanism gradually built around all this information.
In Issue 135, I wrote that CocoaPods is on its way out, while SwiftPM has only just turned to its second chapter. With CocoaPods Trunk counting down toward becoming read-only, and ecosystems such as Flutter also moving toward SPM, the “unification” of dependency management on Apple platforms now seems increasingly close. But that does not mean SwiftPM has truly broken beyond its existing boundaries. It will certainly become the default answer on Apple platforms, but if Swift is to keep expanding into Linux, Android, Wasm, embedded systems, and other scenarios, SwiftPM will need to address more than just “whether dependencies can be installed.” The real question is whether the entire ecosystem is transparent, reliable, and sustainable enough.
In this regard, the value of SPI may be far greater than its name suggests. It can be an index, but also an ecosystem dashboard; it can be a documentation hosting platform, but also a compatibility lab. In the future, it may even take on a larger role in areas such as package collections, supply chain security, version immutability, and public registries. Dave has previously mentioned that SwiftPM registries could bring safer and faster distribution to Swift dependency management, while a public registry for open-source packages remains an important missing piece worth looking forward to.
iOS Dev Weekly records the weekly ripples of the Swift community, while Swift Package Index touches the waterline beneath those ripples. Dave’s shift may also suggest that the Swift ecosystem has entered a new stage: we still need excellent content curators, but we need even more infrastructure builders who can help the ecosystem continue running for the long term.
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
Monads are Easy
Monad is probably one of the most infamous — and most intimidatingly explained — concepts in functional programming. But at its core, it really just solves one problem: how to safely and continuously compose computations around values that carry “context.” Krishna Kotecha explains Monad in a way that feels very approachable to Swift developers, using a warehouse book-scanning analogy: values are books, containers are boxes, map scans books one by one, while flatMap opens nested boxes and flattens everything back into a single box. Whether it’s Optional, Result, or Optional chaining, they all exhibit strong Monad-like behavior. In Swift, every ?. you write is essentially a flatMap disguised as syntax sugar.
Krishna Kotecha not only explains Monads in an intuitive way, but also includes excellent diagrams throughout the article. The “unboxing and repacking” visuals make the core idea behind
flatMapremarkably easy to grasp.
Type-Driven Design in Swift: Better Money Formatting
For many Swift developers, Type-Driven Design often stops at “preventing invalid parameters from being passed around.” But in more complex domains — such as finance, state machines, permissions, or orders — types themselves can become part of the business rules and domain constraints. In this article, Uwais Alqadri uses the separation of “raw money value” and “display value” as a starting point to explain why fintech applications should never perform calculations directly on Double values or formatted display strings. Through a series of practical examples, the article demonstrates how locale differences, currency precision, and rounding rules can introduce subtle but serious bugs, while also highlighting the value of Type-Driven Design in domain modeling.
Is AndroidX ViewModel the best choice for KMP projects?
For Swift developers, a ViewModel is usually just an object that holds view state and interaction logic. In SwiftUI, it can be an @Observable type or simply a reference type organized around view state; task lifecycles are typically managed by .task, the view hierarchy, or other SwiftUI-native mechanisms. But when Swift developers enter the Kotlin Multiplatform or Android ecosystem, it’s easy to underestimate what AndroidX ViewModel is actually responsible for: it’s not only the “ViewModel” in MVVM, but also part of Android’s lifecycle management, ViewModelStore, and coroutine scope system.
Gustavo Fão Valvassori walks through the historical background of Android ViewModel, explaining why it became tightly coupled to Activity / Fragment recreation, configuration changes, and viewModelScope, and further explores the friction this model can introduce when brought into KMP projects targeting native iOS UI. For Swift developers, the most valuable aspect of the article is not whether AndroidX ViewModel should be adopted directly, but rather understanding that the term “ViewModel” can carry very different architectural responsibilities across platforms.
Deprecating your own convenience API
To support different OS versions — or provide a consistent experience across old and new systems — developers often create wrappers, compatibility layers, or custom modifiers to smooth over platform differences. But as deployment targets rise over time, much of that code quietly turns into “dead code” nobody dares to remove. Majid Jabrayilov demonstrates a very practical SwiftUI technique using @available(..., deprecated:, obsoleted:) to explicitly define the lifecycle of these transitional APIs. Once the minimum deployment target increases, the compiler can automatically surface warnings or even errors, reminding developers to finally remove obsolete compatibility layers.
In a sense,
@availableis not only about API availability — it’s also a way to manage the expiration date of technical debt.
Hiding SwiftUI Views from Screen Capture
SwiftUI has long lacked a capability that sounds deceptively simple, yet is actually quite low-level and highly practical: allowing a View to remain visible on screen while being excluded from screenshots, screen recordings, AirPlay, or other system capture pipelines. Public APIs mainly provide “capture state detection,” rather than true per-view capture privacy protection. Kyle Ye, the developer behind OpenSwiftUI, walks through the entire stack — from public APIs, secure UITextField tricks, and the private CALayer.disableUpdateMask behavior, all the way down to SwiftUI’s internal DisplayList and RendererEffect mechanisms — eventually implementing a genuinely SwiftUI-style view extension. Instead of moving SwiftUI content into a secure text field subtree, the approach directly leverages SwiftUI’s existing screencaptureProhibited rendering property to exclude the corresponding layer from capture output.
A Public Symbol Server for Swift on Windows
The Browser Company recently made its Swift on Windows Symbol Server publicly available. Through this service, developers can directly fetch PDB symbol files for the Swift runtime and standard library inside native Windows debugging tools such as WinDBG, Visual Studio, and Windows Performance Analyzer, enabling fully symbolicated stack traces and much clearer crash analysis.
What makes the article particularly interesting, however, is not just how to configure a Symbol Server, but the broader explanation of Swift’s debugging infrastructure across platforms: from object file formats like Mach-O, ELF, and PE/COFF, to DWARF versus PDB/CodeView debug information systems, and the very different ways Darwin, Linux, and Windows manage symbols. For developers who have only worked on Apple platforms, this article offers a surprisingly clear reminder that making Swift truly cross-platform involves far more than simply “being able to compile and run.”
Replacing Bash with Swift in an AI Harness
As AI Agent tooling evolves, “letting models execute code” is gradually becoming less of a terminal wrapper problem and more of a runtime design problem. This article documents a fascinating experiment: Alejandro Martinez replaces Bash inside an AI Harness with an embeddable Swift interpreter, allowing the model to generate and execute Swift directly instead of shell scripts. Combined with SwiftScript and ShellKit, the project demonstrates how embedded interpreters, controlled working directories, and sandboxing can provide a much more constrained and controllable Swift Runtime for LLMs.
SwiftScript is a particularly interesting experimental project created by Oliver Drobnik: a fully Swift-written, embeddable Swift interpreter. It parses and executes Swift ASTs directly using
swift-syntax, rather than compiling binaries throughswiftc, making it feel much closer to JavaScriptCore or a Python-style embedded scripting runtime.
Hanging on the Promise of SwiftUI
Seven years after SwiftUI’s introduction, we still seem to be in a strange in-between state: it has become too important for Apple platform developers to ignore, yet it still feels incomplete enough that many real-world applications eventually fall back to AppKit or UIKit. In this article, Patrick McConnell expresses his complicated relationship with SwiftUI: it is good enough to make developers want to invest deeply in it, but that also makes its recurring “almost, but not quite there” limitations in extensibility, completeness, and lower-level capabilities especially frustrating.
I’ve always felt that SwiftUI will only truly mature once Apple itself fully commits to using it at scale across first-party applications. Third-party developers should not be treated as framework beta testers — they should be the first to benefit from the convenience and stability the framework promises.
Tools
App Store & Google Play Screenshots Generator
App Store & Google Play Screenshots Generator is an AI coding agent–oriented screenshot generation skill created by Parth Jadhav. Rather than simply offering templates, it turns the entire screenshot workflow — collecting product information, organizing marketing copy, choosing visual styles, local editing, and exporting multiple sizes — into an executable process.
The project generates a local Next.js + ShadCN editor for the current directory, supporting drag-and-drop ordering, inline title editing, real screenshot uploads, iOS / Android device switching, and persistent project state stored in a versionable app-store-screenshots.json file. Its most valuable idea is treating store screenshots explicitly as advertising assets: each screenshot should communicate a single selling point, prioritizing user benefit, emotion, and pain points over mechanically showcasing UI.
For indie developers, tools like this are genuinely useful. They won’t replace final visual judgment or platform guideline reviews, but they can consolidate a large amount of repetitive and error-prone screenshot work into a much more agent-friendly local workflow.
Editorio: A Native macOS Markdown & Code Editor
Tired of bloated Electron editors and the ever-growing subscription culture around note-taking apps, Lovre Crncevic decided to build a lightweight, fully native Markdown and code editor for himself.
Editorio uses Swift + AppKit for its native interface and a Rust-powered text engine for performance optimization. It supports live Markdown preview, project sidebars, minimaps, themes, and syntax highlighting for many programming languages. According to the author, Editorio typically uses around 40MB of memory while maintaining near-instant startup and file loading times. In some ways, it feels like a return to the classic era of “small and fast” Mac applications.
Lovre has promised that the app will remain free forever, and mentioned in a Reddit discussion that once the codebase is cleaned up further, he plans to open source Editorio on GitHub.
Event
Swift Mentorship Program 2026
The Swift Mentorship Program is an official community initiative that has become a recurring part of the Swift ecosystem in recent years. Its goal is to help more developers meaningfully participate in Swift open source development through direct mentorship from experienced contributors. Over a 10-week period, mentees work alongside mentors to complete real open-source contributions — whether to the Swift compiler itself or any Swift-based open-source project. Compared to simply reading tutorials or browsing issue trackers, this “guided first contribution” model provides a much more authentic open-source collaboration experience.
The program was originally driven by the Swift Contributor Experience Workgroup and has gradually evolved into a stable community activity. Beyond technical learning, it also helps lower barriers to entry, cultivate new contributors, and strengthen community connections. The Swift team explicitly encourages participation from groups such as Women in Swift, Black in Swift, and Pride in Swift.
The 2026 program has already opened, with mentor and mentee sign-ups beginning in May and June respectively, followed by the official 10-week mentorship cycle starting in July.
Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.
从社区路标到生态基石：Dave Verwer 的新篇章
Dave Verwer 在 iOS Dev Weekly 第 751 期宣布，这份已经持续近 15 年的周报将交由新的团队继续运营，而他自己接下来会全职投入 Swift Package Index。我的博客在早期获得关注，也曾得益于 iOS Dev Weekly 的推荐；而我在周报中坚持撰写每期周评，同样在很大程度上受到 Dave Verwer 的启发。对于很多 Apple 平台开发者来说，iOS Dev Weekly 早已不只是一份链接合集。它既是社区路标，也是长期陪伴。
不过，相较于“Dave 离开 iOS Dev Weekly”这个略带告别感的表述，我更愿意把这件事看作一次重心转移：从整理 Swift 社区的信息流，转向建设 Swift 生态的基础设施。
Swift Package Index 最初由 Dave Verwer 和 Sven A. Schmidt 共同创建，是 SwiftPM Library 的继承者与重构版。刚出现时，它很容易被理解为一个“找 Swift 包的网站”。但几年过去后，SPI 已经明显超出了普通索引站点的范畴。它不仅记录包的基本信息，也通过真实构建来验证不同 Swift 版本和平台的兼容性，托管 DocC 文档，展示维护状态、依赖关系、许可证、测试与质量评分，还通过 Ready for Swift 6 这样的项目，观察整个包生态向新语言特性迁移的进度。
这些能力看似分散，实际上指向的是同一件事：让 Swift 包生态变得更可判断、更可比较，也更可信。对于个人开发者来说，选择依赖时可以少一点“开盲盒”；对于团队来说，在引入第三方库前能更清楚地评估风险；对于包作者来说，也多了一个展示项目健康度和文档质量的公共窗口。一个成熟的包生态，不能只靠 Package.swift 存在。它还需要可见的兼容性、持续的文档、稳定的构建验证，以及围绕这些信息逐渐形成的信任机制。
我在 第 135 期 中提到：CocoaPods 正在退场，SwiftPM 才刚翻到第二章。随着 CocoaPods Trunk 进入只读倒计时，Flutter 等跨平台生态也开始转向 SPM，Apple 平台依赖管理的“大一统”看起来已经越来越接近。但这并不意味着 SwiftPM 已经完成了真正意义上的破圈。它当然会成为 Apple 平台的默认答案，可如果 Swift 想在 Linux、Android、Wasm、嵌入式等更多场景中继续扩展，SwiftPM 需要面对的就不只是“能不能安装依赖”，而是整个生态是否足够透明、可靠、可持续。
在这一点上，SPI 的价值可能比它的名字暗示的要大得多。它可以是索引，也可以是生态仪表盘；可以是文档托管平台，也可以是兼容性实验室；未来甚至有机会在包集合、供应链安全、版本不可变性、公共 registry 等方向上承担更多角色。Dave 此前也曾提到，SwiftPM registry 能为 Swift 依赖管理带来更安全、更快的分发方式，而公共开源 registry 仍是一个值得期待的空白。
iOS Dev Weekly 记录的是 Swift 社区每周的涟漪，而 Swift Package Index 触及的则是这些涟漪之下的水位。Dave 的转身，或许也说明 Swift 生态已经走到一个新阶段：我们仍然需要好的内容策展者，但更需要能让整个生态长期运转下去的基础设施建设者。
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 Buy Me a Coffee 支持我的创作。
近期推荐
轻松理解 Monad (Monads are Easy)
Monad 可能是函数式编程中“名气最大、解释最吓人”的概念之一，但它真正解决的问题，其实只是如何在“带上下文”的值之间，安全、连续地组合计算。Krishna Kotecha 用 Swift 开发者容易理解的方式，通过“仓库扫描书籍”的类比，把 Monad 拆解成了一个极其具体的流程 —— 值是书、容器是箱子、map 是逐个扫描，而 flatMap 则负责拆开嵌套箱子并重新压平成一个统一的箱子。无论是 Optional、Result，还是链式 Optional chaining，本质上都带有明显的 Monad 风格。在 Swift 中，你写下的每一个 ?.，本质上都是一个伪装成语法糖的 flatMap。
Krishna Kotecha 不仅把 Monads 讲得十分直观，文章中的配图也相当出色。这些“拆箱再装箱”的流程图，把
flatMap的核心思想展现得非常形象。
Swift 类型驱动设计：更好的金额格式化 (Type-Driven Design in Swift: Better Money Formatting)
对很多 Swift 开发者来说，Type-Driven Design 往往停留在“避免传错参数”的层面。但在涉及金额、状态机、权限、订单等复杂业务时，类型本身其实也可以成为业务规则与领域约束的一部分。Uwais Alqadri 在本文中，以“金额的原始值与展示值必须分离”为切入点，讨论了为什么金融类应用不应直接使用 Double 或格式化后的展示文本参与金额计算。文章不仅通过多个实际案例说明了不同 locale、货币精度与 rounding rule 带来的潜在问题，也进一步引出了 Type-Driven Design 在业务建模中的价值。
AndroidX ViewModel 是 KMP 项目的最佳选择吗？(Is AndroidX ViewModel the best choice for KMP projects?)
对于 Swift 开发者来说，ViewModel 通常只是一个承载视图状态与交互逻辑的对象。在 SwiftUI 中，它可以是一个 @Observable 类型，也可以只是一个围绕 View 状态组织起来的普通引用类型；任务生命周期往往交给 .task、视图层级或其他更贴近 SwiftUI 的机制处理。但当 Swift 开发者进入 Kotlin Multiplatform 或 Android 生态时，很容易低估 AndroidX ViewModel 所承担的职责：它不仅是 MVVM 中的“ViewModel”，同时也是 Android 生命周期、ViewModelStore 与 coroutine scope 的一部分。
Gustavo Fão Valvassori 从 Android ViewModel 的历史背景讲起，解释它为何会与 Activity / Fragment 的重建、配置变化和 viewModelScope 深度绑定，并进一步讨论当这一套机制被带入 KMP 项目后，在 iOS 原生 UI 中可能产生的摩擦。对于 Swift 开发者而言，文章最有价值的地方并不在于是否应该直接采用 AndroidX ViewModel，而是帮助我们理解：同样叫作 ViewModel，在不同平台上可能承载着完全不同的架构责任。
如何优雅地废弃自定义兼容 API (Deprecating your own convenience API)
为了兼容不同的系统版本，或为新旧系统提供一致的行为与体验，开发者通常会通过统一封装、为旧系统补齐兼容实现，或者用自定义 modifier 抹平不同系统之间的行为差异。但随着应用最低支持版本不断提高，其中很多代码最终都会悄悄变成没人敢删的“死代码”。Majid Jabrayilov 以一个非常典型的 SwiftUI 场景为例，利用 @available(..., deprecated:, obsoleted:) 标记这些“过渡 API”的生命周期。当最低部署版本提升后，编译器会自动将这些兼容层标记为 warning 甚至 error，从而提醒开发者及时移除。
某种意义上，
@available不仅是在管理 API 的可用性，也是在管理“技术债的保质期”。
让 SwiftUI View 在截图中隐藏
SwiftUI 一直缺少一个看似简单、但其实相当实用且底层的能力：让某个 View 在屏幕上正常显示，但在截图、录屏、投屏或其他系统捕获路径中被隐藏。公开 API 提供的更多是“捕获状态检测”，而不是真正意义上的捕获隐私保护。OpenSwiftUI 的开发者 Kyle Ye 从公开 API、secure UITextField 技巧、CALayer.disableUpdateMask 私有行为，一路分析到 SwiftUI 内部 DisplayList 与 RendererEffect 的工作机制，最终实现了一个真正 SwiftUI 风格的视图扩展。它不需要把 SwiftUI 内容塞进 secure text field subtree，而是直接利用 SwiftUI 内部已经存在的 screencaptureProhibited rendering property，将对应 layer 从 capture output 中移除。
Windows 平台 Swift 公共符号服务器上线 (A Public Symbol Server for Swift on Windows)
The Browser Company 近日公开了 Swift on Windows 的 Symbol Server。通过该服务，开发者可以在 WinDBG、Visual Studio、Windows Performance Analyzer 等 Windows 原生调试工具中，直接获取 Swift Runtime 与标准库的 PDB 符号文件，从而获得完整的符号化调用栈与更清晰的崩溃分析能力。
这篇文章真正有趣的地方，并不仅仅是如何配置 Symbol Server，而是它系统梳理了 Swift 在不同平台上的调试基础设施：从 Mach-O、ELF、PE/COFF 等对象文件格式，到 DWARF 与 PDB/CodeView 两套调试信息体系，再到 Darwin、Linux 与 Windows 在 symbol 管理上的不同设计。对于长期只在 Apple 平台开发的 Swift 开发者来说，这篇文章会让你第一次比较直观地意识到：Swift 想真正成为跨平台语言，仅仅“能够编译运行”远远不够，它还需要深入融入目标平台原生的调试体系与工具链生态。
在 AI 容器中用 Swift 替代 Bash (Replacing Bash with Swift in an AI Harness)
随着 AI Agent 工具的发展，“让模型执行代码”正在逐渐从简单的 terminal 调用演变成新的运行时设计问题。这篇文章记录了一个相当有趣的实验：Alejandro Martinez 尝试在 AI Harness 中，用可嵌入的 Swift 解释器替换 Bash，让模型不再生成 shell script，而是直接生成并执行 Swift 代码。结合 SwiftScript 与 ShellKit，展示了如何通过嵌入式解释器、受控工作目录与 sandbox，为 LLM 提供一个更可控的 Swift Runtime。
SwiftScript 是一个相当有意思的实验性项目，由 Oliver Drobnik 创建：一个完全由 Swift 编写、可嵌入应用的 Swift 解释器。它基于
swift-syntax解析并直接执行 Swift AST，而不是通过swiftc编译生成二进制，因此更接近 JavaScriptCore 或 Python Runtime 这类“嵌入式脚本运行时”。
对 SwiftUI 的纠结与期许 (Hanging on the Promise of SwiftUI)
SwiftUI 发布七年后，我们似乎仍处于一种微妙的状态：它已经足够重要，重要到几乎所有 Apple 平台开发都无法绕开它；但它又依然不够完整，很多稍微复杂一点的真实应用，最终仍不得不重新回到 AppKit / UIKit。Patrick McConnell 在这篇文章中，集中表达了他对 SwiftUI 的复杂情绪：它很好，好到让人愿意持续投入；但也正因为如此，当它在扩展性、完整性与底层能力上始终“差一点”时，才会显得格外令人沮丧。
我一直觉得，只有苹果在第一方应用上真正全力、大规模地使用 SwiftUI，SwiftUI 才可能进入更快的成熟期。第三方开发者不应成为框架的小白鼠，而应该优先享受到框架带来的便利与稳定。
工具
App Store & Google Play Screenshots Generator
App Store & Google Play Screenshots Generator 是一个面向 AI coding agent 的商店截图生成 skill，由 Parth Jadhav 开发。它不是简单给你一套截图模板，而是把“收集产品信息 → 组织卖点文案 → 选择视觉风格 → 本地编辑 → 批量导出尺寸”的流程做成了一个可执行工作流。
项目会为当前目录生成一个 Next.js + ShadCN 的本地编辑器，支持拖拽排序、在线修改标题、上传真实截图、切换 iOS / Android 设备，并将项目状态保存为可版本化的 app-store-screenshots.json。它最值得借鉴的地方，是把商店截图明确视为广告素材：每张图只表达一个卖点，优先呈现用户收益、情绪和痛点，而不是机械展示 UI。
对独立开发者来说，这类工具很实用。它不能替代最终的审美判断和平台规则核对，但能把上架截图制作中大量重复、琐碎、容易出错的部分收拢到一个 agent 友好的本地流程里。
Editorio: macOS 原生 Markdown 与代码编辑器
Lovre Crncevic 因为不甘忍受 Electron 编辑器的臃肿，以及各类笔记软件泛滥的订阅制，决定为自己打造一款纯原生的轻量级 Markdown 与代码编辑器。
Editorio 使用 Swift + AppKit 构建原生界面，并使用 Rust 构建底层文本引擎以提升性能，支持 Markdown 实时预览、项目侧边栏、minimap、主题切换，以及多种编程语言的语法高亮。作者表示，Editorio 典型内存占用约 40MB，而冷启动与文件读取则保持在毫秒级响应。某种程度上，它让人重新想起了过去那些“小而快”的经典 Mac 应用。
Lovre 承诺，该应用永久免费，并在 Reddit 上的讨论中表示：等项目代码进一步整理后，他计划将 Editorio 在 GitHub 上开源。
5.1 版本对非英文的输入支持有问题，我已反馈作者。5.2 版本（审查中）中已解决。
活动
2026 年度 Swift 官方导师计划 (Swift Mentorship Program 2026)
Swift Mentorship Program 是 Swift 社区近年来持续举办的一项官方 Mentorship 活动，旨在帮助更多开发者真正参与 Swift 开源生态。项目通过导师配对的方式，让参与者在 10 周时间内，与经验丰富的 Swift 开发者共同完成一次真实的开源贡献：既可以是 Swift 编译器本身，也可以是任意使用 Swift 编写的开源项目。相比单纯的线上教程或 issue 列表，这种“带着新人真正完成一次贡献”的方式，显然更接近真实的开源协作体验。
该项目最早由 Swift Contributor Experience Workgroup 推动，近几年已经逐渐成为 Swift 社区固定活动之一。除了技术学习外，它也承担着降低社区参与门槛、培养新贡献者以及加强社区群体连接的作用。官方还特别鼓励 Women in Swift、Black in Swift 与 Pride in Swift 等社区成员参与其中。
2026 年度活动已经开启，Mentor 与 Mentee 的报名时间分别从 5 月与 6 月开始，7 月正式进入为期 10 周的 Mentorship 周期。
WWDC26 派对之夜：城市、场次和报名信息
WWDC26 主题演讲将于当地时间 06 月 08 日 10:00 在库比蒂诺举行。
作为连续多年入选 Apple 开发者网站 WWDC 社区活动的 WWDC.playground，由 SwiftGG 发起的 WWDC26.playground 线下观影派对将于北京时间 06 月 08 日晚间至 06 月 09 日凌晨，在北京、上海、广州、深圳、杭州和青岛等多座城市举办。
入场时间和报名费用等形式，在不同城市/场次间可能有所不同，请以实地情况为准。👉 各地报名方式