场景定位
用 Codex 搭建、构建和调试 iPhone/iPad SwiftUI 应用：保持 CLI-first build loop，优先用 `xcodebuild`，必要时引入 Tuist、XcodeBuildMCP 和 iOS 专用 skills 来驱动模拟器、截图、日志与 UI 自动化。
- 难度
- 高级
- 时间跨度
- 约 1 小时
适合用于
- 从零搭建 iOS SwiftUI 应用，并希望 Codex 同时生成 app scaffold 和 build loop
- 现有 iPhone/iPad 项目需要 Codex 获取 schemes、模拟器输出、截图或 UI 自动化证据
- 希望长期 iOS UI 任务保持 agentic 和 CLI-first，而不是依赖 Xcode GUI 的团队
Skills & Plugins
相关工具
Starter Prompt
起步提示词
Scaffold a starter SwiftUI app and add a build-and-launch script I can wire to a `Build` action in my local environment.
Constraints:
- Stay CLI-first. Prefer Apple's `xcodebuild`; if a cleaner setup helps, it's okay to use Tuist.
- If this repo already contains a full Xcode project, use XcodeBuildMCP to list targets, pick the right scheme, build, launch, and capture screenshots while you iterate.
- Reuse existing models, navigation patterns, and shared utilities when they already exist.
- Keep the app focused on iPhone and iPad unless I explicitly ask for a shared Apple-platform implementation.
- Use a small trustworthy validation loop after each change, then expand to broader builds only when the narrower check passes.
- Tell me whether you treated this as a greenfield scaffold or an existing-project change.
Deliver:
- the app scaffold or requested feature slice
- a small build-and-launch script with the exact commands
- the smallest relevant validation steps you ran
- the exact scheme, simulator, and checks you used搭建 app 和 build loop
Greenfield 工作可以先从普通 prompt 开始：让 Codex 搭建一个 starter iOS SwiftUI app，并写一个小的 build-and-launch script，方便你接到本地环境里的 Build action。
`xcodebuild` 可以从终端列出 schemes，并执行 build、test、archive、build-for-testing 和 test-without-building。这样 Codex 可以留在 agentic loop 里，而不是频繁切回 Xcode GUI。
如果你希望项目生成更干净，且可以接受第三方工具，Tuist 是一个好选择。它能生成和构建 Xcode project，同时仍然让 Codex 从终端构建和启动应用。
进入完整 Xcode 项目后，如果需要 scheme、target、simulator 控制、截图、日志和 UI 交互，就可以使用 XcodeBuildMCP。那时 shell 命令已经不足以覆盖整个自动化循环。
启用 skills
第一版通常不一定需要 skill 或 MCP server。等工作变得专门化，或者你希望 SwiftUI 约定内置到运行流程里，再加入 skills。
常见的 iOS/SwiftUI skills 可以覆盖通用 SwiftUI best practices、现代 API 可维护性和 accessibility、iOS 26 Liquid Glass、SwiftUI performance、Swift concurrency、view refactor，以及更稳定的 `@Observable`、`@Environment` 架构模式。
安装和使用 skills 时，应把目标设备、deployment target、验证命令和要保持的导航/模型约定写清楚，让 Codex 更容易复用现有 app 结构。
- SwiftUI expert：通用 SwiftUI 最佳实践。
- SwiftUI Pro：现代 API、可维护性、accessibility 和 performance 评审。
- Liquid Glass expert：采用 iOS 26 Liquid Glass API 并调优自定义组件。
- SwiftUI performance：定位常见 SwiftUI 性能问题并生成优先级报告。
- Swift concurrency expert：处理复杂并发诊断和编译器警告。
- SwiftUI view refactor / SwiftUI patterns：拆小文件并保持架构一致。
迭代
有了第一版，或者从现有项目开始后，就可以迭代 UI 与行为。这里的关键是具体说明想改什么，以及希望用什么方式验证它。
prompt 层要显式：告诉 Codex 它是在 greenfield repo 还是现有 Xcode 项目里工作，哪些 iOS 设备或 deployment targets 必须继续可用，以及你期待的验证循环是什么。
对现有 app，要求 Codex 复用已有 models、navigation patterns 和 shared utilities；除非明确需要，否则不要把工作扩大成共享 Apple-platform 实现。
实用提示
从基础开始。Greenfield 工作先用普通 prompt，让 Codex 搭建 starter SwiftUI app，并写一个可以接入本地 Build action 的 build-and-launch script。第一版通常不需要 MCP server。
使用小而可信的验证循环。每次变更后，让 Codex 运行最窄但能证明当前 contract 的命令；等窄检查通过后，再扩大到更重的 build 或 test。
保持 CLI-first。`xcodebuild` 足以覆盖 schemes、build、test、archive 等很多动作，这能让 Codex 继续在终端里自主运行。
需要深入自动化时再使用 XcodeBuildMCP：scheme、target、simulator、screenshots、logs 和 UI interaction 足够重要时，它比单纯 shell 命令更合适。
技术栈
快速原型化 iPhone 和 iPad 视图、导航和共享状态，同时保持 UI 代码可读。
让原生构建循环留在终端里，而不是依赖 Xcode GUI。
当 Codex 需要检查 schemes 和 targets、启动 app、捕获截图并持续迭代时，这是强选项。
让 agent 保持在流程内，把 app build 直接发送到 App Store。