关于使用 SwiftUI 为 Mac 构建辅助应用程序的 WWDC 26 更新 - Paulo 的博客

我上一篇关于使用 SwiftUI 构建 Mac 支持的应用程序的文章比我预期的更受欢迎。 Mastodon 上多次提到它，包括在 iOS Dev Weekly 中，启发了 5 月版的 Swift Blog Carnival，并最终被 John Gruber 在 Daring Fireball 上提到，他可以说是推广“Mac-assed”一词的罪魁祸首。

所有这些关注也导致苹果公司的一位工程师伸出了一些笔记。我们交换了几封电子邮件，我提交了一些雷达，现在 WWDC 26 已经过去了，这篇文章是对我之前写的问题的一个小更新。

选定的州

关于选定的状态，有一个 .backgroundProminence 环境值，当我写上一篇文章时我没有意识到。

根据文档，“像列表和表格这样的视图以及像 ShapeStyle.selection 这样的标准形状样式将自动更新前景视图的背景突出度。”

这意味着 SwiftUI 已经有一个内置概念，与我所说的 .isEmphasized 非常接近。如果您使用的是 List 或 Table ，则可以在选择突出度发生变化时检查此值。

当然，如果您不使用列表或表格 - 如果您尝试进行任何类型的认真定制，您可能不会使用 - 我之前提到的方法仍然是可行的方法。跟踪你自己的注意力，并将这种状态通过环境传递下去。

不同之处在于您可以重用 .backgroundProminence 而不是创建自己的 .isEmphasized 值。这有一个很好的副作用，如果您将来将自定义行放置在列表或表格中，则可以使它们更加兼容。

我还提交了 FB23095823，其中包含一些关于 List 可以公开哪些内容以使自定义行更有用的想法。我仍然认为这是正确的方向。当您使用 AppKit 或 UIKit 时，您的单元格和行具有极大的灵活性，并且我提出的反馈试图使 List 更接近可能的情况。

拖放

有一个新的 .onDragSessionUpdated API ，针对 27 个操作系统版本引入，并且显然已经在 macOS 26 上可用，它解决了我在 SwiftUI 中拖放的最大问题：从一开始就可以了解拖动会话。

我还没有对此进行测试，但从纸面上看，它似乎正是缺失的部分。您最终应该能够在拖动开始时更新您的 UI，并在会话结束时可靠地清理它，即使拖放发生在您的视图之外。

这正是 AppKit 多年来一直能够做到的事情，因此很高兴看到 SwiftUI 在这里更接近。

话虽如此，我的应用程序通常支持最后两个主要操作系统版本，所以我可能只会在两年内开始使用它。

另外值得注意的是 27 版本中新的 .reorderable 修饰符。如果您只是希望允许重新排序，那么这应该是正确的选择。

键盘快捷键

正如我之前提到的，.onMoveCommand 在 iOS 上不可用。解决方法是使用较低级别的抽象，例如 .onKeyPress ，它也适用于 macOS。

这确实有效，但并不完全相同。 .onMoveCommand 是更合适的 API，因为它处理意图。我真的不在乎用户按下向下箭头键。我关心用户想要向下移动。

起初我假设 .onMoveCommand 在 iOS 上不可用，因为 UIResponder 没有匹配的 move* 选择器。然后我注意到 .onMoveCommand 在 tvOS 上可用。

所以现在我又开始认为这只是 API 可用性差距。如果它在 tvOS 上有意义，那么它在 iPadOS 上也绝对有意义，因为在 iPadOS 上硬件键盘很常见，并且期望使用箭头键导航。

我为此提交了 FB23095985。这些微小的平台差异恰恰削弱了跨平台 UI 框架的前景。它们孤立起来很小，但当您尝试共享真实的 UI 代码时，它们会迅速增加。

其他抱怨

对于我提到的其他问题，我提交了 FB23097100，因为无法知道上下文菜单当前是否打开，并提交了 FB23102836，以改进工具栏 API 的人体工程学。

上下文菜单问题仍然让我感到特别沮丧。如果您不尝试构建合适的 Mac 界面，那么这种事情只会显得微不足道。在iOS上，系统可以直观地抬起参与交互的项目。在 macOS 上，应用程序需要足够的信息来表示目标本身。

关于工具栏，WWDC 26 引入了新的 .visibilityPriority 修饰符，可帮助管理哪些项目应首先移至溢出菜单。这对我的问题没有太大帮助，但我觉得我应该提一下。