Need
UI フレームワーク
Default options
Why it's needed
シーンを軸に Mac アプリを構成し、ウィンドウ、サイドバー、ツールバー、設定を実装する際の第一候補です。
.md to the page URL.
Codex use case
Codex を使って、SwiftUI で Mac ネイティブアプリのひな形を作成し、ビルドとデバッグを行います。
Codex を使って SwiftUI で macOS アプリを開発し、シェルからビルドと起動を繰り返せるようにします。開発が進んだら、Mac に適したシーンやウィンドウを追加し、AppKit との連携やコード署名を開発手順に組み込みます。
Codex を使って、SwiftUI で Mac ネイティブアプリのひな形を作成し、ビルドとデバッグを行います。
Codex を使って SwiftUI で macOS アプリを開発し、シェルからビルドと起動を繰り返せるようにします。開発が進んだら、Mac に適したシーンやウィンドウを追加し、AppKit との連携やコード署名を開発手順に組み込みます。
Codex を使って SwiftUI で macOS アプリを開発し、シェルからビルドと起動を繰り返せるようにします。開発が進んだら、Mac に適したシーンやウィンドウを追加し、AppKit との連携やコード署名を開発手順に組み込みます。
Related links
| Skill | Why use it |
|---|---|
| Build macOS Apps | シェルを中心に macOS アプリのビルドとデバッグを行い、Mac に適したシーンとウィンドウを SwiftUI で設計します。必要に応じて AppKit と連携し、コード署名と公証の手順を整えます。 |
新しい Mac アプリを作るときは、まず WindowGroup、Window、Settings、MenuBarExtra、DocumentGroup の中から、アプリに合うシーンモデルを選ぶよう Codex に依頼します。こうすれば、iOS 風の ContentView を後から拡張することなく、最初からデスクトップ向けに設計できます。
ビルドと起動はシェルから繰り返せるようにします。Xcode プロジェクトでは xcodebuild を使います。Swift パッケージを中心に構成したアプリでは、swift build と、プロジェクト内のラッパースクリプト script/build_and_run.sh を使います。このスクリプトで既存のプロセスを停止し、アプリをビルドして新しいビルドを起動します。必要に応じて、ログやテレメトリも確認できるようにします。
SwiftPM だけで構成した GUI アプリでは、実行ファイルを直接起動せず、.app としてバンドルしてから起動します。これにより、ローカルで検証するときに、アプリが Dock に表示されない、アクティブにならない、バンドルが正しく識別されないといった問題を避けられます。
デスクトップ固有の機能を扱う段階になったら、Build macOS Apps プラグインを追加します。シェルからのビルドとデバッグ、SwiftPM アプリのパッケージ化、SwiftUI のネイティブなシーンとウインドウの構成、AppKit との連携、統合ログ、テスト失敗の原因の切り分け、署名と公証の手順を扱えます。
プラグインやスキルのインストール方法と使い方については、プラグインのドキュメントとスキルのドキュメントを参照してください。
iOS のナビゲーションパターンよりも、Mac で一般的な操作方法を優先します。サイドバーと詳細ビューを並べるレイアウトには NavigationSplitView を使い、環境設定には専用の Settings シーンを定義します。操作を見つけやすくするにはツールバーやコマンドを、いつでも呼び出せる軽量なユーティリティにはメニューバーエクストラを使います。
まずはシステムのマテリアル、セマンティックカラー、標準コントロールを使います。独自のデスクトップ UI が必要な場合に限り、ウインドウの外観をカスタマイズしたり、ドラッグ領域や Liquid Glass を使った表示領域を追加したりします。
SwiftUI だけでは一部の動作を実現しきれない場合は、その部分に限って AppKit とのブリッジを追加します。たとえば、ファイルを開くパネルや保存パネルの表示、ファーストレスポンダの制御、メニュー項目の有効性の判定、ドラッグ&ドロップの細かな挙動の処理、専用コントロールを 1 つ実装するための NSView のラップなどが該当します。
実行時の挙動を調べるには、ウインドウを開いたとき、サイドバーの選択を変えたとき、メニューコマンドを実行したとき、バックグラウンドで同期したときなどに、Logger でイベントをいくつか記録するよう Codex に依頼します。アプリを起動したら、log stream でそれらのイベントを確認します。
テストが失敗した場合は、まず問題を調べるのに必要な最小限の範囲で xcodebuild test または swift test を実行するよう Codex に依頼します。その結果を基に、コンパイルエラー、アサーション失敗、クラッシュ、断続的なテスト失敗、環境やセットアップの問題のどれに該当するかを切り分けてもらいます。
ローカルでの開発から配布に移る段階で、Xcode で手動でアーカイブを作成する手順と、リリースのたびに同じ手順でアーカイブ作成と公証を行うためのスクリプトの両方を用意するよう Codex に依頼します。codesign と plutil でアプリバンドル、エンタイトルメント、強化されたランタイムの設定を確認してもらいます。アップロードもターミナルで行いたい場合は、App Store Connect CLI を使います。
アプリ全体を 1 つの巨大なビューにまとめず、メインウインドウ、設定ウインドウ、ユーティリティウインドウ、メニューバーエクストラをそれぞれ独立したシーンのルートとして定義します。
独自のサイドバー、ツールバー、マテリアルを作る前に、SwiftUI 標準のシーン API とウインドウ API で、Mac 上で求める動作を実現できるか確認します。
デスクトップ向けの機能が 1 つ足りない場合は、NSViewRepresentable、NSViewControllerRepresentable、または用途を絞った NSWindow ヘルパーで補います。選択状態とアプリの状態は、引き続き SwiftUI で一元管理します。
ローカルで起動できても、アプリが署名済みか、公証を受ける準備が整っているかは判断できません。個別のリリース確認用に、Xcode で手動でアーカイブを作成する手順を残しておきます。配布を繰り返し同じ手順で行えるように、アーカイブの作成と公証を行うスクリプトも追加します。配布に向けた作業では、codesign と plutil で確認します。
Need
Default options
Why it's needed
Need
UI フレームワーク
Default options
Why it's needed
シーンを軸に Mac アプリを構成し、ウィンドウ、サイドバー、ツールバー、設定を実装する際の第一候補です。
Need
AppKit との連携
Default options
Why it's needed
Mac アプリに必要な動作を SwiftUI だけで実現できない場合は、NSViewRepresentable、NSViewControllerRepresentable、または NSWindow を使い、その部分だけを AppKit で補います。
Need
ビルドとパッケージ化
Default options
xcodebuild、swift build、 App Store Connect CLI
Why it's needed
ローカルでのビルド、手動でのアーカイブ作成、スクリプトによる公証、App Store へのアップロードを、ターミナルから同じ手順で繰り返せます。
| Need | Default options | Why it's needed |
|---|---|---|
| UI フレームワーク | SwiftUI | シーンを軸に Mac アプリを構成し、ウィンドウ、サイドバー、ツールバー、設定を実装する際の第一候補です。 |
| AppKit との連携 | AppKit | Mac アプリに必要な動作を SwiftUI だけで実現できない場合は、 NSViewRepresentable 、 NSViewControllerRepresentable 、または NSWindow を使い、その部分だけを AppKit で補います。 |
| ビルドとパッケージ化 | xcodebuild 、 swift build 、 App Store Connect CLI | ローカルでのビルド、手動でのアーカイブ作成、スクリプトによる公証、App Store へのアップロードを、ターミナルから同じ手順で繰り返せます。 |