Codex のiOSアプリ開発のためのプロンプトまとめ

以下の記事が面白かったので、簡単にまとめました。

1. iOSアプリのビルド

1.1 はじめに

iOS SwiftUIプロジェクトのひな形を作成するには「Codex」を使用し、ビルドループは「xcodebuild」または「Tuist」を使用してCLI優先で進め、作業が高度化するにつれて「XcodeBuildMCP」やSwiftUIに特化したスキルを追加します。

1-2. スキルとプラグイン

1-3. アプリのスケルトン化とビルドループの構築

アプリの新規開発は、シンプルなプロンプトから始めます。CodexにiOS SwiftUIスターターアプリのスケルトン化を依頼し、ローカル環境でビルドアクションに紐付けられる小さなビルド＆起動スクリプトを作成します。

ループはCLIファーストで進めます。Appleの「xcodebuild」は、スキームの一覧表示、ビルド、テスト、アーカイブ、テスト用ビルド、ビルドなしテストといったアクションをターミナルから実行できるため、CodexはXcode GUIに切り替えずにエージェントループ内で作業を続けることができます。

よりクリーンなプロジェクトジェネレーターが必要で、サードパーティツールの使用に慣れている場合は、「Tuist」が次のステップとして適しています。TuistはGUIを必要とせずにXcodeプロジェクトを生成・ビルドでき、Codexはターミナルからアプリのビルドと起動を行うことができます。

Xcodeプロジェクト全体を扱い、より高度な自動化が必要になった場合は、「XcodeBuildMCP」を使用します。スキーム、ターゲット、シミュレーター制御、スクリーンショット、ログ、UI操作などが重要になり、単純なシェルコマンドだけでは対応できなくなる段階です。

1-4. スキルの活用

最初の段階では、スキルやMCPサーバーは必ずしも必要ありません。作業が専門的になったり、より強力なSwiftUIの規約を実装したい場合に、スキルを追加してください。

スキルのインストール方法と使用方法について詳しくは、スキルのドキュメントを参照してください。

1-5. 反復作業

最初のバージョンが動作するようになったら、または既存のプロジェクトから始める場合は、UIや動作の反復作業を開始できます。

この段階では、変更したい内容と変更方法を具体的に記述してください。プロンプトレイヤーを明確に定義してください。Codexに対して、新規リポジトリで作業しているのか、既存のXcodeプロジェクトで作業しているのか、どのiOSデバイスまたはデプロイメントターゲットで動作を維持する必要があるのか​​、そしてどのような検証ループを期待しているのかを伝えてください。

1-6. プロンプト例

既存のアプリに機能を追加したい場合、Codexに次のような変更依頼を行うことができます。

Add the onboarding flow for this SwiftUI app.

Constraints:

- Reuse existing models, navigation patterns, and shared utilities.
- Use XcodeBuildMCP to list the right targets or schemes, build the app, launch it, and capture screenshots if you need visual verification.
- Keep the implementation focused on iPhone and iPad unless I explicitly ask for a shared iOS/macOS abstraction.
- Tell me exactly which scheme, simulator, and checks you used.

Implement the slice, verify it with the smallest relevant build or run loop, and summarize what changed.

1-7. 実践的なヒント

2. SwiftUI画面のリファクタリング

2-1. はじめに

Codexと「Build iOS Apps」プラグインを使用して、長いSwiftUIビューを専用のセクションビューに分割し、副作用をbodyから分離し、StateとObservationの使用を安定させ、不要なビューモデルを導入するのではなく、MVファーストのリファクタリングを維持します。

2-2. スキルとプラグイン

2-3. スタータープロンプト

Use the Build iOS Apps plugin and its SwiftUI view refactor skill to clean up [NameOfScreen.swift] without changing what the screen does or how it looks.

Constraints:
- Preserve behavior, layout, navigation, and business logic unless you find a bug that must be called out separately.
- Default to MV, not MVVM. Prefer `@State`, `@Environment`, `@Query`, `.task`, `.task(id:)`, and `onChange` before introducing a new view model, and only keep a view model if this feature clearly needs one.
- Reorder the view so stored properties, computed state, `init`, `body`, view helpers, and helper methods are easy to scan top to bottom.
- Extract meaningful sections into dedicated `View` types with small explicit inputs, `@Binding`s, and callbacks. Do not replace one giant `body` with a pile of large computed `some View` properties.
- Move non-trivial button actions and side effects out of `body` into small methods, and move real business logic into services or models.
- Keep the root view tree stable. Avoid top-level `if/else` branches that swap entirely different screens when localized conditional sections or modifiers are enough.
- Fix Observation ownership while refactoring: use `@State` for root `@Observable` models on iOS 17+, and avoid optional or delayed-initialized view models unless the UI genuinely needs that state shape.
- After each extraction, run the smallest useful build or test check that proves the screen still behaves the same.

Deliver:
- the refactored screen and any extracted subviews
- a short explanation of the new subview boundaries and data flow
- any places where you intentionally kept a view model and why
- the validation checks you ran to prove behavior stayed intact

2-4. 動作を変更せずに画面をリファクタリング

このユースケースは、SwiftUIファイルが巨大な画面に膨れ上がり、ちょっとした変更でもリスクが伴うような状況を想定しています。目的は、機能を再設計したり、新しいアーキテクチャを構築したりすることではありません。Codexに動作とレイアウトを維持するように指示し、画面を明確なデータフローを持つ小さなサブビューに分割することで、次の変更のレビューを容易にします。

このようなクリーンアップには、「Build iOS Apps」プラグインを使用してください。このプラグインのSwiftUIビューリファクタリング機能は、有用な方法で設計思想に基づいています。MVVMよりもMVを優先し、ビジネスロジックはサービスまたはモデルに保持し、ローカルビューの状態と環境依存関係を優先的に使用し、機能にビューモデルが明らかに必要な場合にのみビューモデルを保持します。

2-5. Codexに依頼する内容

まず、具体的な画面ファイルを1つ指定し、Codexに動作を維持しつつ構造を改善するよう依頼します。プロンプトに直接記述する価値のあるリファクタリングルールは以下のとおりです。

2-6. 小規模な検証ループを要求する

動作を維持するリファクタリングには、その証拠が必要です。Codex に、意味のある抽出を行うたびに、画面を検証する最小限のビルド、プレビュー、テスト、またはシミュレーターチェックを実行するように依頼し、構造的に変更された部分と意図的に変更されなかった部分を要約してもらいます。

2-7. 実践的なヒント

3. Liquid Glass の採用

3-1. はじめに

Codexと「Build iOS Apps」プラグインを使用して、既存のiPhoneおよびiPadのUIを監査し、カスタムのぼかし効果やマテリアルスタックをネイティブの「Liquid Glass」に置き換え、iOS 26の可用性チェックとシミュレーターによる検証で移行の安全性を確保します。

3-2. スキルとプラグイン

3-3. スタータープロンプト

Use the Build iOS Apps plugin and its SwiftUI Liquid Glass skill to migrate one high-traffic flow in this app to Liquid Glass.

Constraints:
- Treat this as an iOS 26 + Xcode 26 migration, but preserve a non-glass fallback for earlier deployment targets with `#available(iOS 26, *)`.
- Audit the flow first. Call out custom backgrounds, blur stacks, chips, buttons, sheets, and toolbars that should become native Liquid Glass and call out surfaces that should stay plain content.
- Prefer system controls and native APIs like `glassEffect`, `GlassEffectContainer`, `glassEffectID`, `.buttonStyle(.glass)`, and `.buttonStyle(.glassProminent)` over custom blurs. Use `glassEffectID` with `@Namespace` only when a real morphing transition improves the flow.
- Apply `glassEffect` after layout and visual modifiers, keep shapes consistent, and use `.interactive()` only on controls that actually respond to touch.
- Use XcodeBuildMCP to build and run on an iOS 26 simulator, capture screenshots for the migrated flow, and mention exactly which scheme, simulator, and checks you used.

Deliver:
- a concise migration plan for the flow
- the implemented Liquid Glass slice
- the fallback behavior for pre-iOS 26 devices
- the simulator validation steps and screenshots you used

3-4. iOS 26をベースラインとして開発を開始

「Liquid Glass」をiOS 26およびXcode 26への移行プロジェクトとして最初に扱います。iOS 26 SDKを使用してアプリを再ビルドし、標準のSwiftUIコントロールから自動的に取得される要素を検証します。その後、Codexに、まだ平坦すぎる、重すぎる、またはシステムクロームから乖離しすぎているカスタムパーツの再設計を依頼します。

アプリが以前のiOSバージョンもサポートしている場合は、その制約を事前に明確にしてください。「Build iOS Apps」プラグインのSwiftUI Liquid Glassスキルは、新しい Liquid Glass 専用API を #available(iOS 26, *) で制限し、古いデバイスでも適切に表示されるフォールバックパスを用意しておく必要があります。

3-5. iOSプラグインの活用

CodexでSwiftUIのUI変更とシミュレーターによる検証を組み合わせたい場合は、「Build iOS Apps」プラグインを使用してください。Liquid Glassの作業では、Codexに1つのフローの監査を依頼し、少数のサーフェスを移行し、iOS 26シミュレーターで結果を起動し、スコープを拡大する前にスクリーンショットをキャプチャするのが効果的です。

このプラグインには、プロンプトに組み込むと便利なデフォルト設定を備えたSwiftUI Liquid Glassスキルが含まれています。

プラグインとスキルのインストール方法について詳しくは、プラグインとスキルのドキュメントを参照してください。

3-6. WWDCのセッションを観る

これらのWWDC25のセッションは、Codexに実際の運用フローのリファクタリングを依頼する前に、参考として活用できます。

3-7. 移行計画を促し、次にスライスを実装

Codex が「どこに Glass を配置するか？」と「今すぐすべてのコードを記述する」を切り離すことで、Liquid Glass の移行はよりスムーズに進みます。まずは簡単な監査を依頼し、その後、エージェントにシミュレーター検証付きの自己完結型スライスを実装させます。

3-8. 実践的なヒント

4. iOSアプリのインテントの追加

4-1. はじめに

Codexと「Build iOS Apps」プラグインを使用して、アプリが「App Intent」を通じて公開すべきアクションとエンティティを特定し、ショートカットやSpotlightなどのシステムインターフェースにそれらを組み込み、将来的にはアシスタント主導のワークフローに対応できるようアプリを準備します。

4-2. スキルとプラグイン

4-3. スタータープロンプト

Use the Build iOS Apps plugin to audit this iOS app and add App Intents for the actions and entities that should be exposed to the system.

Constraints:
- Start by identifying the app's highest-value user actions and core objects that should be available outside the app in Shortcuts, Siri, Spotlight, widgets, controls, or newer assistant-driven system surfaces.
- Keep the first pass focused. Pick a small set of intents that are genuinely useful without opening the full app, plus any open-app intents that should deep-link into a specific screen or workflow.
- Define app entities only for the data the system actually needs to understand and route those actions. Do not mirror the entire internal model layer if a smaller entity surface is enough.
- Add App Shortcuts where they make the experience more discoverable, and choose titles, phrases, and display representations that would make sense in Siri, Spotlight, and Shortcuts.
- If the app needs to handle the intent inside the main UI, route the result back into the app cleanly and explain how the app scene reacts to that handoff.
- Build and validate the app after the first pass, then summarize which actions, entities, and system surfaces are now supported.

Deliver:
- the recommended intent and entity surface for a first release
- the implemented intents, entities, and App Shortcuts
- how the app routes or handles those intents at runtime
- which Apple system experiences this unlocks now and which ones are logical next steps

4-4. アプリの適切な部分をシステムに公開

「App Intents」は、iOSアプリを独自のUI以外でもより便利にするための方法の1つです。アプリを起動して操作した後でなければ機能しない閉鎖的な場所として扱うのではなく、Codexを使用して、ショートカット、Siri、Spotlight、ウィジェット、コントロール、そして新しいアシスタント主導のシステム体験で利用できるアクションとオブジェクトを公開します。

これは、発見性と自動化のために現在すでに役立っており、よりアシスタント主導の未来に向けた強力な準備段階となります。アプリが既に価値のあるものを作成、開く、フィルタリング、ルーティング、要約する方法を知っている場合、App Intentsは、その機能をシステムに要求するための構造化された方法を提供します。

4-5. すべての画面ではなく、アクションとエンティティからはじめる

「App Intents」の最初の試みとして最適なのは、通常「アプリ全体をミラーリングする」ことではありません。 Codexに以下の項目を特定してもらいましょう。

Appleの「App Intents」に関するガイダンスは、この点において有効な枠組みとなります。まず操作を定義し、次にシステムが必要とするエンティティインターフェースを定義し、最後にそれらの操作をシステム全体で検出可能かつ再利用可能にします。

参考になる資料は、次のとおりです。

4-6. ショートカットだけでなくシステムインターフェース全体で考える

可能性は「ショートカットを1つ追加する」だけにとどまりません。優れたアプリインテントインターフェースは、アプリをさまざまな場面で活用できるようにします。

4-7. 実際のアプリ開発パターンに従う

通常、アプリが次のような構造を採用すると最も効果的です。

これが、ほとんどのアプリで Codex に採用してほしいパターンです。まず、システムと直接やり取りするアクションレイヤーを小さくし、エンティティのインターフェースを限定的にし、インテントがメインUIを必要とする際には、予測可能なランタイムハンドオフをアプリに組み込むようにします。

4-8. Codexに最初のインテントサーフェスの設計を依頼

最も効果的な指示は、アプリのコアオブジェクトと主要なユーザーアクションをCodexに伝え、すべてを無闇に公開するのではなく、最小限の有用な最初のアプリインテントサーフェスを選択するように依頼することです。

4-9. 実践的なヒント

5. iOSシミュレータでのデバッグ

5-1. はじめに

Codex を使用すると、適切な Xcodeスキームとシミュレーターを見つけ、アプリを起動し、UI ツリーを検査し、タップ、入力、スワイプを行い、スクリーンショットとログをキャプチャし、必要に応じて LLDB を添付して、漠然としたバグ報告を検証済みの小さな修正に変換できます。

5-2. スタータープロンプト

Use the Build iOS Apps plugin and XcodeBuildMCP to reproduce this bug directly in Simulator, diagnose the root cause, and implement a small fix.

Bug report:
[Describe the expected behavior, the actual bug, and any known screen or account setup.]

Constraints:
- First check whether a project, scheme, and simulator are already selected. If not, discover the right Xcode project or workspace, pick the app scheme, choose a simulator, and reuse that setup for the rest of the session.
- Build and launch the app in Simulator, then confirm the right screen is visible with a UI snapshot or screenshot before you start interacting with it.
- Drive the exact reproduction path yourself by tapping, typing, scrolling, and swiping in the simulator. Prefer accessibility labels or IDs over raw coordinates, and re-read the UI hierarchy before the next action when the layout changes.
- Capture evidence while you debug: screenshots for visual state, simulator logs around the failure, and LLDB stack frames or variables if the bug looks like a crash or hang.
- If the simulator is not already booted, boot one and tell me which device and OS you chose. If credentials or a special fixture are required, pause and ask only for that missing input.
- Make the smallest code change that addresses the bug, then rerun the simulator flow and tell me exactly how you verified the fix.

Deliver:
- the reproduction steps Codex executed
- the key screenshots, logs, or stack details that explained the bug
- the code fix and why it works
- the simulator and scheme used for final verification

5-3. Codexにシミュレーターの全ループを任せる

このユースケースは、Codexがループ全体を管理する場合に最も効果的です。適切なアプリターゲットを選択し、シミュレーターでアプリを起動し、現在の画面を検査し、再現手順を実行し、ログとスクリーンショットを収集し、必要に応じてスタックトレースを検査し、コードにパッチを適用し、同じパスを再実行してバグが解消されたことを確認します。

ループをCodexに任せたい場合は、「Build iOS Apps」プラグインを使用してください。このプラグインのiOSデバッガーワークフローは「XcodeBuildMCP」を基盤としているため、Codexは起動したシミュレーターと連携し、人間が通常手動で収集するのと同じ証拠を収集できます。

「XcodeBuildMCP」がシミュレーター自動化、UI自動化、デバッグ、ログ記録ワークフローで構成されている場合、Codexは再現・デバッグ・検証の全ループを管理できます。Codexがまだプロジェクト、スキーム、シミュレーターを選択していない場合は、まずそれらを検出させ、その設定をセッションの残りの部分で再利用してください。

5-4. XcodeBuildMCPの機能を活用

Codexに実行を促すための実用的な機能グループは以下のとおりです。

重要なのは、Codex がタップする前にビューツリーを検査するように指示することです。「XcodeBuildMCP」はアクセシビリティ階層と座標を公開するため、Codex は生の画面位置を推測するのではなく、安定したラベルや要素 ID を優先的に使用できます。

5-5. 漠然としたバグを再現可能なスクリプトに変換

iOSデバッガースキルは、具体的なバグと期待される結果を一つずつ指定した場合に最も効果を発揮します。Codexがアプリを操作し、証拠を自律的に収集します。ログイン、ディープリンク、またはテストフィクスチャが必要な場合は、その旨を一度だけ伝え、入力が不足している場合にのみCodexに一時停止を指示してください。

5-6. 実践的なヒント

関連