场景定位
用 Codex 和 Build macOS Apps 插件搭建或迭代 macOS SwiftUI 应用：先定义 scene 和 shell-first build loop，再实现桌面原生 UI、调试、测试与打包路径。
- 难度
- 高级
- 时间跨度
- 约 1 小时
适合用于
- 从零搭建 macOS SwiftUI app，并需要桌面原生 shell 和可复用 build script
- 现有 Mac app 需要处理 windows、menus、sidebars、settings、AppKit interop 或签名问题
- 希望 macOS 工作保持 shell-first，同时尊重原生桌面 UX 约定的团队
Skills & Plugins
相关工具
Starter Prompt
起步提示词
Use the Build macOS Apps plugin to scaffold a starter macOS SwiftUI app and add a project-local `script/build_and_run.sh` entrypoint I can wire to a `Run` action.
Constraints:
- Stay shell-first. Prefer `xcodebuild` for Xcode projects and `swift build` for package-first apps.
- Model Mac scenes explicitly with a main window plus `Settings`, `MenuBarExtra`, or utility windows only when they fit the product.
- Prefer desktop-native sidebars, toolbars, menus, keyboard shortcuts, and system materials over iOS-style push navigation.
- Use a narrow AppKit bridge only when SwiftUI cannot express the desktop behavior cleanly.
- Keep one small validation loop for each change and tell me exactly which build, launch, or log commands you ran.
Deliver:
- the app scaffold or requested Mac feature slice
- a reusable build-and-run script
- the smallest validation steps you ran
- any desktop-specific follow-up work you recommend先搭建 app 和 build loop
新 Mac app 应先让 Codex 选择 scene model：`WindowGroup`、`Window`、`Settings`、`MenuBarExtra` 或 `DocumentGroup`。这能避免应用从一个 iOS 风格的 `ContentView` 长出来。
执行循环保持 shell-first。Xcode project 用 `xcodebuild`；package-first app 用 `swift build`，并提供项目本地 `script/build_and_run.sh` wrapper，用于停止旧进程、构建 app、启动新产物，并可选择打开 log capture。
如果纯 SwiftPM GUI app 需要像真正 App 一样运行，应该 bundle 并启动 `.app`，而不是直接运行 raw executable，这能避免 Dock、activation 和 bundle identity 问题。
启用相关 skills
当工作变得更 Mac-specific 时，加入 Build macOS Apps 插件。它覆盖桌面窗口、scene、AppKit bridge、统一日志、测试分类、签名和 notarization 等本地开发细节。
把 build/run 命令、日志捕获、UI 验证和签名边界写进 prompt 或 AGENTS.md，Codex 更容易保持每个小改动都有验证循环。
构建桌面原生 UI
优先使用 Mac 约定，而不是 iOS navigation。侧边栏/详情布局使用 `NavigationSplitView`，偏好设置放进显式 `Settings` scene，重要动作进入 toolbar、commands 和 keyboard shortcuts。
先用 system materials、semantic colors 和标准控件。只有产品确实需要独特桌面表面时，再增加 custom window styling、drag regions 或 Liquid Glass surfaces。
如果 SwiftUI 接近但不够，添加最小 AppKit bridge。好例子包括 open/save panels、first-responder control、menu validation、拖放边缘和为一个特殊控件包装 `NSView`。
调试、测试并准备发布
对运行时行为，让 Codex 在 window opening、sidebar selection、menu commands 或 background sync 周围添加少量 `Logger` 事件，并在 app 启动后用 `log stream` 验证。
对失败测试，先运行最小有用的 `xcodebuild test` 或 `swift test` 范围，并把问题分类为 compilation、assertion failure、crash、flake 或环境/setup。
当工作从本地迭代进入分发，要求 Codex 同时准备 Xcode 手动 archive 路径和脚本化 archive/notarization 路径，并检查 app bundle、entitlements 和 hardened runtime。
示例提示词
使用上方 starter prompt，并把产品概念、目标窗口结构、构建方式和验证命令补齐。
实用提示
- 保持 scenes 显式：main window、settings window、utility windows 和 menu bar extra 不要藏进一个巨大 view。
- 让系统 chrome 做更多工作：先检查标准 SwiftUI scene/window APIs 是否已经给出需要的 Mac 行为。
- 把 AppKit 当作窄边界：只为 SwiftUI 表达不清的具体桌面行为 bridge。
技术栈
Mac scenes、窗口、侧边栏、工具栏、菜单和 Settings 的默认实现路径。
用于 SwiftUI 无法清晰表达的 open/save panels、first-responder、menu validation 或特殊 NSView 控件。
保持 shell-first build/run 验证，同时为 archive、签名和 notarization 留出可复用路径。