swiftui-advanced

SwiftUI の高度なパターン

ジェスチャーの合成、アダプティブレイアウト、アーキテクチャの選択、パフォーマンスの最適化に関する SwiftUI の高度なパターンです。

リファレンスの読み込みガイド

内容が必要になる可能性が少しでもある場合は、必ずリファレンスファイルを読み込んでください。 パターンを見落としたり、間違えたりするより、事前にコンテキストを把握しておくほうが適切です。

リファレンス	読み込むタイミング
Gestures	複数のジェスチャーの合成、GestureState、カスタム認識器を扱う場合
Adaptive Layout	ViewThatFits、AnyLayout、サイズクラス、iOS 26 のフリーフォームウィンドウを扱う場合
Architecture	MVVM と TCA の選択、State-as-Bridge、プロパティラッパーの選定を行う場合
Performance	Instruments 26、ビューの body の最適化、不要な更新を扱う場合

基本的なワークフロー

1. ユーザーの質問からパターンのカテゴリを特定します
2. 詳細なパターンとコード例について、関連するリファレンスを読み込みます
3. 判断ツリーとアンチパターンに従ってパターンを適用します
4. 提供されたチェックリストやプロファイリングの指針を使って検証します

判断ツリー

ジェスチャーの合成

• 2 つのジェスチャーを同時に認識する必要がありますか？ -> .simultaneously
• 次のジェスチャーの前に、1 つ目を完了させる必要がありますか？ -> .sequenced
• どちらか一方だけを優先する必要がありますか？ -> .exclusively

レイアウトの適応

• 最適なバリエーションを選びますか？ -> ViewThatFits
• H/V の切り替えをアニメーション化しますか？ -> AnyLayout
• 実際のサイズが必要ですか？ -> onGeometryChange

アーキテクチャの選択

• 小規模なアプリで、Apple のパターンを使いますか？ -> @Observable + State-as-Bridge
• 複雑なプレゼンテーションロジックがありますか？ -> @Observable を使った MVVM
• 厳密なテスト容易性が必要ですか？ -> TCA

よくある間違い

1. ジェスチャーの合成順序は重要です — .simultaneously と .sequenced では、発火のタイミングが異なります。順序を入れ替えると、動作が気づかないうちに変わります。使用する前にジェスチャーのセマンティクスを理解してください。

2. ViewThatFits の過剰な使用 — ViewThatFits はビューが変わるたびに再計測を行います。アニメーション付きで H/V を切り替える場合は、代わりに AnyLayout を使用してください。ViewThatFits は静的なバリエーションの選択にのみ使用してください。

3. onGeometryChange による不要な更新 — ジオメトリを読み取るとジオメトリが変化し、それによって更新が発生し、さらにジオメトリが変化する……という循環が起こります。ループを避けるため、適切な状態管理のもとでのみ .onGeometryChange を使用してください。

4. プロジェクト途中でのアーキテクチャの不一致 — @Observable + State-as-Bridge で始めた後に TCA が必要だと気づくと、変更に大きなコストがかかります。複雑さに応じて、事前にアーキテクチャを選択してください（小規模なアプリ = @Observable、複雑なアプリ = TCA）。

5. ビューの body の最適化を怠る — ビューの body でコストの高い計算を繰り返し行うと、パフォーマンスが大きく低下します。計算はプロパティまたはモデルに移してください。時期尚早な最適化を避けるため、最適化の前に Instruments 26 でプロファイリングしてください。