xcode-project-analyzer

Xcode プロジェクトアナライザー

ソースコードの編集だけでは解決できそうにない、プロジェクトまたはターゲットレベルのビルド効率の問題にこのスキルを使用してください。

基本ルール

• 原則として、推奨事項を最初に提示します。
• プロジェクトファイル、スキーム、ビルド設定を変更する前に、明示的な承認を得てください。
• タイミングの概要、ビルドログ、またはプロジェクト設定の根拠に基づき、測定された結果を優先してください。
• デバッグ専用の問題とリリース専用の問題を区別してください。

確認する項目

• スキームのビルド順序とターゲットの依存関係
• ビルド設定のベストプラクティスに照らした、デバッグとリリースのビルド設定
• 実行スクリプトフェーズと依存関係分析の設定
• Derived Data の更新頻度、または明らかに無効化を引き起こすカスタム手順
• 並列化の機会
• 明示的なモジュール依存関係の設定と、モジュールマップへの対応状況
• Build Timing Summary の「Planning Swift module」にかかる時間。インクリメンタルビルドで大半を占める場合は、予期しない入力の変更やマクロ関連の無効化を疑ってください
• アセットカタログのコンパイル時間。特に、カタログが大規模または多数あるターゲット
• Build Timing Summary の ExtractAppIntentsMetadata にかかる時間。このフェーズが大きな時間を消費する場合は、xcode-behavior として記録してください（コストと影響を報告しますが、Apple の明示的なガイダンスがない限り、リポジトリ内での最適化は提案しないでください）
• 変更のないビルドのオーバーヘッド。何も変更していない状態での再ビルドに数秒以上かかる場合は、スクリプト実行、codesign、検証、CopySwiftLibs など、固定コストのフェーズを調査してください
• CocoaPods の使用状況。Podfile または Pods.xcodeproj が存在する場合、CocoaPods は非推奨です。SPM への移行を推奨し、CocoaPods 固有の最適化は試みないでください（project-audit-checks.mdを参照）
• Task Backtraces（Xcode 16.4 以降：Scheme Editor > Build > Build Debugging）。インクリメンタルビルドでタスクが予期せず再実行される理由を診断するために使用します

ビルド設定のベストプラクティス監査

すべてのプロジェクト監査で、build-settings-best-practices.mdの推奨値とプロジェクトの Debug および Release の設定を比較するビルド設定チェックリストを含めてください。結果はチェックマーク／バツ印（[x]／[ ]）を使って提示してください。対象はビルドパフォーマンスに厳密に限定してください。SWIFT_STRICT_CONCURRENCY や SWIFT_UPCOMING_FEATURE_* など、言語移行に関する設定は指摘しないでください。

Apple のガイダンスに基づく確認項目

監査のたびに、以下を確認してください。

• ターゲットの依存関係が正確で、過不足がないこと
• スキームが Dependency Order でビルドされること
• 実行スクリプトで入力と出力が宣言されていること
• スクリプトの入力または出力が多い場合に、.xcfilelist ファイルが使用されていること
• カスタムフレームワークやライブラリがモジュールマップを公開する必要がある場合、DEFINES_MODULE が有効になっていること
• ヘッダーがモジュールマップで利用できる程度に自己完結していること
• モジュールを共有する必要があるターゲット間で、明示的なモジュール依存関係の設定が一貫していること

典型的な改善点

• リリース時のみ必要なスクリプトを、デバッグ時にはスキップする
• 不足しているスクリプトのガードや依存関係分析メタデータを追加する
• スキーム内の意図しない直列化によるボトルネックを取り除く
• 不要なモジュールバリアントを引き起こすビルド設定を揃える
• 必要以上に広範囲な再ビルドを引き起こす古いプロジェクト構造を修正する
• 内容を変更せずにファイルのタイムスタンプを更新することで、ビルド入力をひそかに無効化し、モジュールの再計画を強制するリンターやフォーマッターを特定する
• 大規模なアセットカタログをターゲット間で個別のリソースバンドルに分割し、コンパイルを並列化する
• Task Backtraces を使用して、不要なインクリメンタル処理を引き起こす入力変更を正確に特定する

報告形式

問題ごとに、以下を含めてください。

• 根拠
• 影響する可能性のある範囲
• クリーンビルド、インクリメンタルビルド、またはその両方に影響する理由
• 推定される影響
• 承認の要否

根拠からパッケージグラフまたはビルドプラグインが問題だと考えられる場合は、spm-build-analysisのSKILL.mdを読み、同じプロジェクトのコンテキストにそのワークフローを適用して引き継いでください。

追加リソース

• 詳細な監査チェックリストについては、references/project-audit-checks.md を参照してください。
• ビルド設定のベストプラクティスについては、references/build-settings-best-practices.md を参照してください。
• 共通の推奨事項の形式については、references/recommendation-format.md を参照してください。
• Apple の方針に沿ったソースの要約については、references/build-optimization-sources.md を参照してください。