Fatbobman's Swift Weekly #154
A “Native” Debate Over SwiftUI AnimationLast week, a post by React Native core developer Krzysztof Magiera sparked a lively discussion across the Apple developer community. In the post, he demonstrated an example where, with the main thread blocked, a back-and-forth animation in UIKit continued to run normally while the equivalent SwiftUI animation came to a halt. He attributed this to SwiftUI not using Core Animation’s render-server animation model and instead advancing animations within the app process, raising the question of whether SwiftUI is truly “native.” He later added that, in React Native, developers can still use Core Animation to create animations that continue running even when the main thread is blocked. SwiftUI co-creator and early core developer Kyle Macomber responded with a different perspective. He explained that, from the beginning, SwiftUI deliberately moved away from server-side animation—where Core Animation advances animations on the render server—and instead chose to compute and advance animation values in the client/app process in exchange for better interruptibility and interactivity. This was not a technical regression, but a deliberate design trade-off. (SwiftUI did not abandon Core Animation itself; Core Animation still participates in the subsequent rendering process. What changed is who advances the animation.) Ease of animation has always been one of SwiftUI’s signature strengths, and the continued evolution of its spring animations in recent years has further improved the naturalness of transitions and the expressiveness of interactive motion. For a reactive framework, I think advancing animations on the client side is entirely understandable. The trade-off, of course, is equally clear: as Krzysztof’s example demonstrates, when animation advancement depends on the app process, it becomes more susceptible to a busy main thread and also consumes more computational resources on the client side. That said, client-side animation does not mean that all animation sampling calculations must happen on the main thread. As SwiftUI has evolved, some computationally intensive work involving animations and This discussion presented an interesting situation: on the surface, the debate was about whether SwiftUI is truly “native,” but underneath it revealed a difference in framework design philosophies. As Apple’s UI framework for the future, SwiftUI chose to depart from the established path, moving away from dependence on Core Animation’s render-server animation model in exchange for more flexible and expressive animation capabilities. In fact, John Harper, the creator of Core Animation, was himself one of SwiftUI’s co-creators. So this choice clearly wasn’t made out of unfamiliarity with Core Animation, but rather as an architectural decision made with an understanding of both its strengths and limitations. It also brought a less obvious advantage: some of SwiftUI’s core capabilities became further decoupled from the specific implementation details of Apple platforms. Although Apple has not open-sourced SwiftUI, architecturally, some of its core ideas are not inherently limited to Apple platforms. From the React Native perspective, Krzysztof’s argument also has its rationale. As a cross-platform framework, one of React Native’s important goals is to make the best possible use of the capabilities each platform already provides, allowing apps to behave and perform more like “locals” on each platform. What began as a discussion about “what counts as native” ultimately led core developers from both sides to explain how they think about UI animation architecture. As someone happily watching from the sidelines, I learned quite a bit from it as well. 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 ☕️ OriginalFrom pbxproj to xcproj: Xcode Project Configuration Gets a JSON FormatI’ve been waiting for Xcode 27.1, hoping to test how my apps adapt in the iPhone Duo simulator. Amusingly, 27.1 never arrived — Apple shipped 27.2 beta first instead. The iPhone Duo simulator is still missing, but the new Recent RecommendationsHow we built Devin’s MacWhen an AI agent runs locally, permissions have long since been granted, the toolchain is ready, and a human can dismiss any dialog that appears. Move to the cloud and every one of those assumptions has to be rebuilt. The payoff isn’t doing something the local machine can’t — it’s turning the development environment itself into a resource you can assign to an agent: tasks run asynchronously, stay isolated from one another, pause and preserve their state when idle, resume on demand, and scale more easily to several agents working in parallel. Jon Kelley walks through building Devin’s macOS cloud environment, covering virtual machines on Virtualization.framework, disk snapshots, network isolation, pre-configured environments and permissions, live streaming of the desktop and Simulator, and computer use driven by the accessibility tree. That last point is especially instructive for Apple developers: good accessibility support also gives agents a structured interface for automated verification. iOS 27: CrashReportExtension FrameworkTraditional crash handling has an awkward problem: by the time the signal handler runs, the process it lives in may already be unreliable — memory may be corrupted, locks may still be held, and many everyday APIs can’t be called safely. The new CrashReportExtension in iOS 27 changes that execution model. After the app crashes, the system launches a separate extension and hands it a read-only Anton Gubarenko demonstrates how to create and use the extension, along with several practical judgments. The API complements Apple’s How SwiftUI animation worksFor animation, developers only change state and specify an animation function, leaving the rest to SwiftUI. But how do those declarations become a continuous sequence of frames on screen? Starting from Transaction and AttributeGraph, and drawing on his work on OpenSwiftUI, Kyle Ye analyzes step by step how SwiftUI creates an animation context, computes intermediate states, and keeps updating views and layout as the animation runs. Unlike the conventional approach of leaving interpolation mostly to the render server, many SwiftUI animations advance within the app process. Because interpolation happens inside the view graph, any value conforming to Animatable can be sampled, which lets layout, Shape, and much more participate in animation, while the render server mainly handles layer properties. The analysis of the SwiftUI: Some New APIs/ContainerViews Useful For Duo!The many poses of iPhone Duo present new challenges for toolbars. To make full use of the wider screen while preserving vertical space for content, the system moves controls normally placed at the top and bottom to the side of the screen in certain poses. But text buttons, custom views, and other traditional toolbar content don’t always suit a vertical arrangement, and the toolbar and tab bar may have to compete for limited side space. iOS 27.1 addresses this with APIs including What these APIs have in common is that they let developers declare a preference rather than dictate a result. Faced with the range of poses Duo introduces, describing the relationships between pieces of content and your layout preferences — and letting SwiftUI decide the final presentation based on the actual environment — beats writing layouts for specific device states. Sheets and fold avoidance on iPhone DuoWhen iPhone Duo is partially folded, the crease down the middle forms a region poorly suited to interaction, and buttons or other controls that land there become awkward to operate. Using sheets as his example, Sarun Wongpatcharapakorn shows how a single interface adjusts its size, position, and toolbar across Duo’s closed, open, landscape, portrait, and partially folded poses. System components including sheets, alerts, and menus already avoid the fold without developer intervention. For developers, that means reaching for system components first also means inheriting this adaptive behavior across device poses for free. ToolsVapor 5 Beta ReleasedTen years after Vapor was born and six and a half years after Vapor 4 shipped, the community finally has the first beta of Vapor 5. It amounts to a near-complete rewrite — two years of work and roughly 49,000 lines changed. The central change is saying goodbye to Vapor 5 also integrates more deeply with Swift HTTP Types, Swift Configuration, and Swift Service Lifecycle, and adds the experimental Hinge: Set the Duo Simulator’s Fold Angle from the Command LineXcode 27.1’s Device Hub can adjust the fold angle of the iPhone Duo Simulator (hold Option to reveal it), but neither Enriched Markdown: Cross-Platform Markdown Rendering and Editing Without a WebViewThe usual way to handle Markdown on mobile is to wrap it in a WebView. Enriched Markdown, from Software Mansion, takes a more thorough route: it renders Markdown and supports rich-text editing through each platform’s native text capabilities, and can emit clean Markdown again once the content has been edited. It offers a standalone SwiftUI SDK, rendering Markdown with TextKit 2 and md4c, and also covers React Native, Android, and the web. Rather than settling for “Markdown that displays,” Enriched Markdown emphasizes a native feel: text selects normally, links, images, and code blocks hook into system menus, and the library supports VoiceOver, TalkBack, Dynamic Type, and right-to-left writing. Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it. 一场关于 SwiftUI 动画的“原生”之争上周，React Native 核心开发者 Krzysztof Magiera 的一条 推文 在苹果开发生态中引发热烈讨论。推文中他展示了一个示例：在主线程阻塞的情况下，UIKit 的一个往返动画仍能正常执行，而 SwiftUI 的动画则停滞了。他认为原因在于 SwiftUI 没有使用 Core Animation 的 render-server animation，而是在应用进程中推进动画，因此对 SwiftUI 是否足够“原生”提出了质疑；随后又表示，在 React Native 中，开发者仍可通过 Core Animation 创建不受主线程阻塞影响的动画。 SwiftUI 共同创造者、早期核心开发者 Kyle Macomber 对此回应了不同的 观点。他解释说，SwiftUI 在设计之初就有意放弃了 Server-side Animation（由 Core Animation 在 render server 中推进动画），而选择让动画值在 client / app process 中计算和推进，以换取更好的可中断性与交互性。这并非技术上的退步，而是一项设计取舍（SwiftUI 并没有放弃 Core Animation，它仍然参与后续的渲染过程，改变的只是动画由谁来推进）。 动画的易用性一直是 SwiftUI 的标志性特色之一，近年来不断完善的弹簧动画，又进一步提升了动画衔接的自然程度和交互表现力。作为一个响应式框架，把动画推进放在 client 端，我认为完全可以理解。当然，代价也很明确：正如 Krzysztof 的示例所示，当动画推进依赖应用进程时，它更容易受到主线程繁忙的影响，也会占用更多 client 端的计算资源。 不过，client-side animation 并不意味着所有插值计算都必须发生在主线程。随着 SwiftUI 不断演进，部分动画以及 Shape 等计算密集型工作已经可以移到后台线程，以减轻主线程的压力。不过，由于动画的推进仍然属于应用进程，异步计算也受到状态更新和渲染流程等条件的限制，因此当主线程被完全阻塞时，动画依然可能停滞。尽管存在这种“弊端”，但从 iOS 18 开始，UIKit 和 AppKit 也开始采纳这套 client-side animation 模型：新的动画 API 可以直接使用 SwiftUI 的 Animation，并由同一套动画基础设施驱动，而不再生成传统的 CAAnimation。 本次讨论呈现出一个有趣的场景：表面上在争论 SwiftUI 是否“原生”，实际展现的却是两种框架设计理念的差异。 作为苹果面向未来的 UI 框架，SwiftUI 在设计时选择走出既有路径，放弃对 Core Animation render-server animation 模型的依赖，以换取更灵活、更强大的动画表达能力。事实上，Core Animation 的创造者 John Harper 本人也是 SwiftUI 的共同创造者之一，这项选择显然不是因为不了解 Core Animation，而是在理解其优势与局限之后做出的架构决定。这还带来了一个隐形优势：SwiftUI 的部分核心能力与苹果平台的具体实现得以进一步解耦。尽管苹果并未将 SwiftUI 开源，但从架构上看，它的一些核心思想并不天然局限于苹果平台。 而从 React Native 的角度看，Krzysztof 的表述也有其合理性。作为一个跨平台框架，React Native 的重要目标之一，就是在不同平台上尽可能利用平台已经提供的能力，让应用在行为和性能上更像“本地人”。 一个最初围绕“什么才算原生”的讨论，最终引出了两边核心开发者对 UI 动画架构的理解与阐述。作为一个吃瓜群众，我也从中收获不少。 如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 Buy Me a Coffee 支持我的创作。 原创从 pbxproj 到 xcproj：Xcode 工程配置迎来 JSON 格式最近一直在等待 Xcode 27.1 的到来，以便在 iPhone Duo 的模拟器中测试一下应用的适配情况。有意思的是，27.1 没等到，苹果率先发布了 27.2 beta。尽管 iPhone Duo 模拟器依然缺席，但新增的 近期推荐为 Devin 构建云上 Mac 开发环境 (How we built Devin’s Mac)当 AI Agent 在本地运行时，权限早已授予，工具链已经就绪，遇到弹窗也可以人工干预。搬到云端后，这些理所当然的条件都需要重新构建。换来的好处并不在于能做到本地做不到的事，而是让开发环境本身成为可以分配给 Agent 的资源：任务可以异步运行、彼此隔离，闲置时暂停并保存状态，需要时再恢复，也更容易支持多个 Agent 并行工作。Jon Kelley 在文中介绍了为 Devin 构建 macOS 云端环境的过程，涵盖基于 Virtualization.framework 的虚拟机、磁盘快照、网络隔离、环境与权限预配置、桌面与 Simulator 的实时串流，以及借助无障碍树实现的计算机操作。最后一点对苹果开发者尤其有启发：做好无障碍支持，也是在为 Agent 的自动化验证提供结构化接口。 iOS 27: CrashReportExtension Framework传统的崩溃处理有一个棘手的问题：当 signal handler 开始工作时，它所在的进程本身可能已经处于不可靠状态，内存可能损坏、锁可能没有释放，很多平时使用的 API 也无法安全调用。iOS 27 新增的 CrashReportExtension 改变了这一执行模型。当 App 崩溃后，系统会启动一个独立的 Extension，并通过只读的 Anton Gubarenko 在文中完整演示了这个扩展的创建与使用，也给出了几条务实的判断。该 API 是对系统 SwiftUI 动画的运作机制 (How SwiftUI animation works)对于动画，开发者只需改变状态并设置动画函数，剩下的工作便交给 SwiftUI。但这些声明最终是如何转化成屏幕上一帧帧连续变化的画面？Kyle Ye 从 Transaction 和 AttributeGraph 出发，结合 OpenSwiftUI 的开发经验，逐步分析 SwiftUI 如何创建动画上下文、计算中间状态，并在动画过程中持续更新视图与布局。 与将动画插值主要交给 render server 的传统方式不同，SwiftUI 的许多动画需要在应用进程中持续推进。由于插值发生在视图图内部，任何满足 Animatable 的值都能被采样，布局、Shape 等更多状态因此得以参与动画，而 render server 主要处理图层属性。文中对异步提交路径中 为 iPhone Duo 准备的新 API (SwiftUI: Some New APIs/ContainerViews Useful For Duo!)iPhone Duo 的多种使用形态给 Toolbar 带来了新的挑战。为了充分利用更宽的屏幕并保留纵向内容空间，系统会在部分形态下将原本位于顶部和底部的控件移到屏幕侧边。但传统 Toolbar 中的文本按钮、自定义视图等内容并不一定适合纵向排列，Toolbar 与 Tab Bar 还可能需要争夺有限的侧边空间。iOS 27.1 为此增加了 这批 API 的共同特征，是让开发者声明偏好而非指定结果。面对 Duo 带来的多种形态，与其针对特定设备状态编写布局，不如描述内容之间的关系和布局偏好，再由 SwiftUI 根据实际环境决定最终呈现方式。 iPhone Duo 上的 Sheet 与折痕规避 (Sheets and fold avoidance on iPhone Duo)当 iPhone Duo 处于部分折叠状态时，中央折痕形成了一块不适合交互的区域，按钮等控件如果恰好落在这里，会变得难以操作。Sarun Wongpatcharapakorn 以 Sheet 为例，展示了同一个界面如何在 Duo 的关闭、展开、横屏、竖屏以及部分折叠等不同形态下调整尺寸、位置和 Toolbar。Sheet、Alert 和菜单等系统组件已经内置折痕规避能力，无需开发者干预。因此对于开发者而言，优先使用系统组件，也意味着可以直接获得这些针对不同设备形态的自适应行为。 工具Vapor 5 Beta 发布在 Vapor 诞生十周年、距离 Vapor 4 发布六年半之际，社区终于迎来了 Vapor 5 的首个 Beta 版本。此次几乎是一次彻底重写——历时两年、变更约 49,000 行代码。最核心的改动是彻底告别 同时，Vapor 5 进一步整合 Swift HTTP Types、Swift Configuration 和 Swift Service Lifecycle，并加入实验性的 Hinge：命令行调节 Duo 模拟器折叠角度Xcode 27.1 的 Device Hub 可以调整 iPhone Duo Simulator 的折叠角度（按住 Option 键可见），但 Enriched Markdown：不依赖 WebView 的跨平台 Markdown 渲染与编辑方案在移动端实现 Markdown，常见方案是套一层 WebView。Software Mansion 推出的 Enriched Markdown 选择了一条更彻底的路线：基于各平台的原生文本能力完成 Markdown 渲染与富文本编辑，并可以将编辑后的内容重新输出为干净的 Markdown。 它提供独立的 SwiftUI SDK，基于 TextKit 2 与 md4c 实现 Markdown 渲染，同时也覆盖 React Native、Android 和 Web。相比单纯追求“能显示 Markdown”，Enriched Markdown 更重视原生体验：文本可以正常选择，链接、图片与代码块能够接入系统菜单，并适配 VoiceOver、TalkBack、动态字体和从右到左书写（RTL）。 Welcome to my blog Fatbobman's Swift Blog( 肘子的Swift记事本 )
|
