WWDC 26 SwiftUI 构建 Mac 辅助应用更新

上一篇关于使用 SwiftUI 构建 Mac 辅助应用程序的文章，热度确实超出了预期。它在 Mastodon 上被多次提及，出现在 iOS Dev Weekly 的 5 月号里，还启发了 Swift Blog Carnival 的 5 月专题，最后甚至被 John Gruber 在 Daring Fireball 上点名——他可以说是那个“Mac-assed”说法的主要推手。

这些关注还引来了苹果工程师的主动联系，来回几封邮件、提交了几个雷达之后，WWDC 26 已经落幕。这篇文章算是对之前那篇内容的一个小更新，整理了一些 SwiftUI 开发中的新发现与改进。

选定的州

关于选定状态，其实有个 .backgroundProminence 环境值，写上一篇文章时并没有注意到。根据文档，“像列表和表格这样的视图，以及像 ShapeStyle.selection 这样的标准形状样式，会自动更新前景视图的背景突出度。” 换句话说，SwiftUI 已经内置了一个与之前说的 .isEmphasized 非常接近的概念。如果正在使用 List 或 Table，可以在选择突出度变化时检查这个值。当然，如果不用列表或表格——进行任何认真的定制化时大概率不会用——之前提到的方法仍然是可行的：自己跟踪注意力状态，并通过环境传递下去。

不同之处在于，现在可以直接重用 .backgroundProminence，而不用创建自己的 .isEmphasized 值。还有个不错的副作用：如果将来把自定义行放到列表或表格中，兼容性会更好，避免了重复造轮子。

另外还提交了 FB23095823，提出了一些关于 List 应该公开哪些内容才能让自定义行更有用的想法。仍然认为这是正确的方向。在 AppKit 或 UIKit 中，单元格和行拥有极大的灵活性，这些反馈正是试图让 List 更接近那种可能性，从而提升 macOS 开发体验。

拖放

一个新 API .onDragSessionUpdated 在 27 个操作系统版本中引入，并且已经在 macOS 26 上可用。它解决了 SwiftUI 中拖放的最大痛点：从一开始就能了解拖动会话。虽然还没实际测试过，但从纸面上看，它正是缺失的那块拼图。最终应该在拖动开始时就能更新 UI，并在会话结束时可靠地清理，即使拖放发生在视图之外，也能确保状态一致。

这正是 AppKit 多年来一直能做到的事情，很高兴看到 SwiftUI 在这里逐渐靠拢，让跨平台开发更顺畅。不过，应用程序通常只支持最后两个主要操作系统版本，所以可能还得等两年才能用上这个 API。

另外值得一提的，是 27 版本中新的 .reorderable 修饰符。如果只是想要允许重新排序，这个应该是首选，简化了列表排序的实现。

键盘快捷键

之前提到过，.onMoveCommand 在 iOS 上不可用。解决方法是使用更低层的抽象，比如 .onKeyPress，它也适用于 macOS。这确实能工作，但感觉不一样。.onMoveCommand 是更合适的 API，因为它处理的是意图——真的不在乎用户按下了向下箭头键，关心的是用户想要向下移动，这更符合语义化编程的理念。

起初以为 .onMoveCommand 在 iOS 上不可用是因为 UIResponder 没有匹配的 move* 选择器，后来发现它在 tvOS 上是可用的。所以现在反而觉得这只是一个 API 可用性上的差距。如果它在 tvOS 上有意义，那么在 iPadOS 上也绝对有意义——毕竟 iPadOS 上硬件键盘很常见，用户期望用箭头键导航，这种不一致会让人困惑。

为此提交了 FB23095985。这些微小的平台差异，恰恰削弱了跨平台 UI 框架的吸引力。单独看都很小，但一旦尝试共享真实的 UI 代码，它们就会迅速累积成麻烦，增加开发成本。

其他抱怨

对于之前提到的其他问题，提交了 FB23097100（无法知道上下文菜单当前是否打开）和 FB23102836（改进工具栏 API 的人体工程学）。上下文菜单问题仍然让人特别沮丧。如果不尝试构建真正的 Mac 界面，这种事情只会被看作鸡毛蒜皮。在 iOS 上，系统可以直观地抬起参与交互的项目；在 macOS 上，应用程序需要足够的信息来自己表示目标，这需要更完善的 API 支持。

关于工具栏，WWDC 26 引入了新的 .visibilityPriority 修饰符，帮助管理哪些项目应优先移入溢出菜单。虽然对之前的问题帮助不大，但值得提一下，也算是一个积极的改进方向。