appkit-interop

AppKit 互操作

快速开始

当 SwiftUI 已经很接近，但仍无法满足原生 macOS 行为需求时，使用此技能。 尽可能让桥接保持精简且明确。通常应由 SwiftUI 继续作为事实来源，而由 AppKit 处理命令式边缘场景。

选择最小的桥接方案

• 如果场景、工具栏、命令、检查器或标准控件已支持所需行为，请使用纯 SwiftUI。
• 如果需要特定的 AppKit 视图，且生命周期需求较简单，请使用 NSViewRepresentable。
• 如果需要控制器生命周期、委托或展示协调，请使用 NSViewControllerRepresentable。
• 如果需要 NSWindow、响应者链、菜单验证、面板或应用级行为，请直接使用 AppKit 窗口或应用钩子。

工作流

1. 准确指出能力缺口。

   • 窗口行为
   • 文本系统行为
   • 菜单验证
   • 拖放
   • 文件打开／保存面板
   • 第一响应者控制

2. 选择能够解决问题的最小边界。

   • 如果只需包装一个控件或使用协调器，就不要把整个屏幕移植到 AppKit。

3. 明确所有权。

   • SwiftUI 拥有值状态、选择状态和可观察模型。
   • AppKit 对象应保留在可表示对象、协调器或桥接对象内部。

4. 向 SwiftUI 暴露精简接口。

   • 用于可编辑状态的绑定
   • 用于事件的简短回调
   • 仅在必要时提供专用桥接服务

5. 验证生命周期假设。

   • SwiftUI 可能会重新创建可表示对象。
   • 协调器用于承载委托和目标－动作衔接代码，而不是充当第二套应用架构。

参考资料

• references/representables.md：如何在视图和视图控制器包装器之间做选择，以及协调器模式。
• references/window-panels.md：窗口访问、实用窗口和打开／保存面板。
• references/responder-menus.md：第一响应者、命令路由和菜单验证。
• references/drag-drop-pasteboard.md：粘贴板、文件 URL 和桌面拖放边缘场景。

护栏

• 不要在 SwiftUI 和 AppKit 之间重复维护事实来源。
• 不要让 Coordinator 变成杂乱无章的代码堆放处。
• 除非有充分的所有权理由，否则不要在全局存储长期存在的 NSView 或 NSWindow 实例。
• 优先采用经过测试的小型桥接方案，而不是用原生 AppKit 重写整个功能。
• 如果某种模式可以完全由 swiftui-patterns 实现，就将其保留在那里。

输出要求

请提供：

• 正在跨越的 SwiftUI 具体限制
• 建议采用的最小桥接类型
• SwiftUI 与 AppKit 之间的数据流边界
• 需要留意的生命周期或验证风险