swift-patterns

swift-patterns

適切な状態管理、最新の API の使用、最適なビュー構成、パフォーマンスを考慮したパターンに基づいて、SwiftUI の機能をレビュー、リファクタリング、または構築します。ネイティブ API、Apple のデザインガイダンス、テストしやすいコード構造を優先します。このスキルでは、特定のアーキテクチャパターンを強制せず、事実とベストプラクティスに焦点を当てます。

ワークフローの判断ツリー

1) 既存の SwiftUI コードをレビューする

→ レビュー方法については references/workflows-review.md を読みます

• プロパティラッパーの選択に照らして状態管理を確認します（references/state.md を参照）
• ビューの構成と抽出のパターンを検証します（references/view-composition.md を参照）
• リストのパフォーマンスと ID の安定性を監査します（references/lists-collections.md を参照）
• 最新の API の使用状況を検証します（references/modern-swiftui-apis.md を参照）
• .task を使った非同期処理のパターンを確認します（references/concurrency.md を参照）
• ナビゲーションの実装を検証します（references/navigation.md を参照）
• レビュー回答テンプレート（以下）を使用します

2) 既存の SwiftUI コードをリファクタリングする

→ リファクタリング方法については references/workflows-refactor.md を読みます

• プレイブックを使って複雑なビューを抽出します（references/refactor-playbooks.md を参照）
• 非推奨 API を最新の代替 API に移行します（references/modern-swiftui-apis.md を参照）
• パフォーマンス上のホットパスを最適化します（references/performance.md を参照）
• 状態の所有権を再構成します（references/state.md を参照）
• 一般的なパターンを適用します（references/patterns.md を参照）
• リファクタリング回答テンプレート（以下）を使用します

3) 新しい SwiftUI 機能を実装する

• まずデータフローを設計します。所有する状態と注入される状態を特定します（references/state.md を参照）
• 最適な構成になるようビューを構成します（references/view-composition.md を参照）
• 最新の API のみを使用します（references/modern-swiftui-apis.md を参照）
• .task 修飾子で非同期処理を扱います（references/concurrency.md を参照）
• パフォーマンスパターンを早い段階で適用します（references/performance.md を参照）
• ナビゲーションフローを実装します（references/navigation.md を参照）

4) ベストプラクティスに関する質問に答える

• トピックに応じて関連するリファレンスファイルを読み込みます（以下のリファレンスファイルを参照）
• 例を交えて、直接的なガイダンスを提示します

意図が不明確な場合は、次のように尋ねます：「確認結果のみを希望しますか（レビュー）、それともコードも変更しますか（リファクタリング）？」

回答テンプレート

レビュー回答：

1. 対象範囲 - レビューした内容
2. 確認事項 - 重要度別にまとめた、具体的な対応が可能な指摘
3. 根拠 - ファイルパスまたはコードの位置
4. リスクとトレードオフ - 破損する可能性がある箇所、または注意が必要な点
5. 次のステップ - 最初に修正または検証する内容

リファクタリング回答：

1. 意図と対象範囲 - 変更内容とその理由
2. 変更点 - ファイルパスを含む箇条書き
3. 動作の維持 - 変更後も維持されるべき動作
4. 次のステップ - 必要なテストまたは検証

クイックリファレンス：プロパティラッパーの選択

ラッパー	使用する場面	所有者
@State	ビュー内部の状態（値型または @Observable クラス）	ビュー
@Binding	子ビューが親の状態を変更する必要がある場合	親ビュー
@Bindable	バインディングを必要とする、注入された @Observable オブジェクト	注入元
let	親から渡される読み取り専用の値	注入元
var + .onChange()	リアクティブな更新が必要な読み取り専用の値	注入元

重要なルール：

• @State は必ず private として宣言します（所有権を明確にするため）
• 渡された値に @State を使用しないでください（初期値のみを受け取ります）
• @Observable クラスには @State を使用します（@StateObject ではありません）

詳しいガイダンスとトレードオフについては references/state.md を参照してください。

クイックリファレンス：最新 API への置き換え

非推奨	最新の代替手段	備考
foregroundColor()	foregroundStyle()	Dynamic Type に対応
cornerRadius()	.clipShape(.rect(cornerRadius:))	より柔軟
NavigationView	NavigationStack	型安全なナビゲーション
tabItem()	Tab API	iOS 18 以降
onTapGesture()	Button	位置や回数が必要な場合を除く
onChange(of:) { value in }	onChange(of:) { old, new in } または onChange(of:) { }	パラメーターは 2 つ、または 0 個
UIScreen.main.bounds	GeometryReader またはレイアウト API	サイズのハードコーディングを回避

移行ガイドの全文は references/modern-swiftui-apis.md を参照してください。

レビューチェックリスト

SwiftUI コードのレビュー時に使用してください。

状態管理

• @State プロパティに private を指定している
• 渡された値を @State または @StateObject として宣言していない
• 子ビューが親の状態を変更する場合に限り @Binding を使用している
• プロパティラッパーの選択が所有権のルールに従っている
• 状態の所有権が明確で、意図的に決められている

最新 API

• 非推奨の修飾子（foregroundColor、cornerRadius など）を使用していない
• NavigationView の代わりに NavigationStack を使用している
• 適切な場合、onTapGesture の代わりに Button を使用している
• 2 つのパラメーターを取る onChange() またはパラメーターを取らない onChange() を使用している

ビューの構成

• 状態変更に条件分岐ではなく修飾子を使用している（アイデンティティを維持）
• 複雑なビューを個別のサブビューに切り出している
• ビューを小さく、焦点を絞ったものにしている
• ビューの body をシンプルかつ純粋に保っている（副作用なし）

ナビゲーションとシート

• 型安全なナビゲーションに navigationDestination(for:) を使用している
• モデルに基づくシートに .sheet(item:) を使用している
• シートが自身の閉じる処理を所有している

リストとコレクション

• ForEach で安定したアイデンティティを使用している（動的データに .indices は使用しない）
• ForEach の各要素が常に一定数のビューを生成している
• ForEach 内でインラインフィルタリングを行っていない（事前にフィルタリングしてキャッシュする）
• リストの行で AnyView を使用していない

パフォーマンス

• ビューに必要な値だけを渡している（大きな設定オブジェクトは渡さない）
• 不要な依存関係を排除している
• 処理頻度の高い箇所では、状態を代入する前に値が変化したか確認している
• 大きなリストには LazyVStack／LazyHStack を使用している
• ビューの body 内でオブジェクトを生成していない

非同期処理

• 自動キャンセルのために .task を使用している
• 値に依存するタスクには .task(id:) を使用している
• 非同期処理に .onAppear を混在させていない

各項目の詳しい説明については、参考ファイルを参照してください。

制約

• Swift／SwiftUI のみを対象 - ブリッジが必要な場合を除き、サーバーサイド Swift と UIKit は対象外
• Swift の並行処理パターンは対象外 - SwiftUI の非同期処理には .task を使用
• アーキテクチャを強制しない - MVVM／MVC／VIPER や特定の構造を必須としない
• フォーマット／Lint のルールは対象外 - 正確性とパターンに重点を置く
• ツール固有のガイダンスは対象外 - Xcode、Instruments、IDE に関する手順は含めない
• 引用可能な資料： developer.apple.com/documentation/swiftui/、developer.apple.com/documentation/swift/

すべてのワークフローで、これらの制約に従う必要があります。

基本方針

このスキルでは、Apple のドキュメントに基づく事実とベストプラクティスに重点を置きます。

• 非推奨の API より最新の API を優先
• 状態の所有権パターンを明確化
• パフォーマンスを意識したビュー構成
• テスト可能なコード構造
• アーキテクチャを強制しない（MVVM／VIPER は必須ではない）
• Apple Human Interface Guidelines に準拠

参照ファイル

references/ 内のすべての参照ファイル：

• workflows-review.md - レビュー手法と指摘事項の分類体系
• workflows-refactor.md - リファクタリング手法と不変条件
• refactor-playbooks.md - 手順ごとのリファクタリングガイド
• state.md - プロパティラッパーと所有権のパターン
• navigation.md - ナビゲーションの実装パターン
• view-composition.md - ビューの構造と抽出
• lists-collections.md - 識別と ForEach のパターン
• scrolling.md - スクロール処理とページネーション
• concurrency.md - .task による非同期処理
• performance.md - 最適化の戦略
• testing-di.md - テストと依存性注入
• patterns.md - SwiftUI の一般的なパターン
• modern-swiftui-apis.md - レガシー API の移行
• code-review-refactoring.md - コード品質チェック