ios-animation-design

iOSアニメーション設計

装飾ではなく、意図が伝わるアニメーションを計画します。AppleのHIGは明確です。「動きを加えること自体を目的に、動きを加えてはいけません。過剰または不必要なアニメーションは、人の注意をそらしたり、疎外感や身体的な不快感を与えたりすることがあります。」すべてのアニメーションには目的が必要です。注意を誘導する、状態の変化を伝える、空間的な関係を強調する、またはフィードバックを提供する、といった目的です。

カスタムアニメーションを追加する前に、次の点を確認してください。システムがすでに対応していないでしょうか。多くのシステムコンポーネントには、モーションが組み込まれています。Liquid Glass（iOS 26）はタッチに対してより強調された反応を返し、トラックパッド操作ではより控えめな効果を生み出します。標準コントロール、ナビゲーション遷移、シートには、すでにアニメーションが用意されています。カスタムモーションは、システムがカバーしていない部分を補うものであり、システムがすでにうまく対応している機能を置き換えるものではありません。

設計プロセス

ゲート（順番に実施）

作業中の成果物（チャットまたはドキュメント）で各合格条件を満たしてから、次に進みます。証拠なしに適合していると判断しないでください。

1. ゲート — コンテキストの記録 — 合格条件： モーションのトリガー、その目的、アプリ内での配置場所、実行頻度、最低iOSバージョン、主な入力方法（該当しない場合は明示的に該当なし）について、回答が記載されていること。合格条件： システムが提供するモーションですでに対応できているか、カスタムアニメーションでどのような不足を補うのかが明記されていること。
2. ゲート — 選択肢の有意な違い — 合格条件： 2～3種類のアプローチがあり、それぞれが次の要素のうち少なくとも2つで異なること：API／手法の名称、モーションの特性、複雑さのレベル、または最低iOSバージョン。同じアイデアのタイミングを少し変えただけのものは含めません。
3. ゲート — 実装可能な仕様 — 合格条件： まとめた仕様に、トリガー、中断（キャンセル／反転／キューイング）、視差効果を減らす設定時の代替動作、触覚フィードバック（または、理由を添えた明示的な「なし」）、推奨APIが具体的に記載されていること。

ステップ1：アニメーションのコンテキストを理解する

選択肢を提示する前に、何を、なぜアニメーション化するのかを把握します。

• 何がトリガーになりますか？ ユーザーの操作（タップ、スワイプ、ドラッグ）、状態の変化（データの読み込み、エラー）、またはライフサイクルイベント（表示、非表示）でしょうか。
• 目的は何ですか？ フィードバック、空間的な方向付け、コンテンツの遷移、楽しさの演出、またはステータスの伝達でしょうか。
• アプリ内のどこで発生しますか？ ナビゲーションフロー、画面内の状態変化、オーバーレイ／モーダル、または背景のアンビエント表示でしょうか。
• どのくらいの頻度で発生しますか？ セッションごとに一度（オンボーディング）、操作のたびに（タブの切り替え）、または継続的に（進行状況インジケーター）でしょうか。AppleのHIGは、「アプリでは一般に、頻繁に発生するUI操作にモーションを追加するのは避けてください。システムが標準のインターフェイス要素を使った操作に、すでに控えめなアニメーションを提供しています」と警告しています。
• デプロイメントターゲットは何ですか？ 利用可能なAPIを決める、最低iOSバージョンはどれでしょうか。
• 入力方法は何ですか？ タッチ、トラックパッド、キーボード、VoiceOverでしょうか。iOS 26のLiquid Glassは入力方法に応じてモーションの強さを調整します。直接のタッチでは強調された反応を返し、間接的な入力ではより控えめになります。カスタムアニメーションも同じ原則に従う必要があります。

ステップ2：アニメーションのアプローチを2～3種類提示する

アニメーションが必要な箇所ごとに、異なるアプローチを2～3種類提示します。それぞれの選択肢は、同じアイデアの細かな違いではなく、意味のある違いがあるものにします。各選択肢は、次の形式で記述します。

### Option [N]: [Name]

**Approach**: [1-2 sentences describing the motion design]
**Technique**: [Which Apple API — SwiftUI animation, KeyframeAnimator, matchedGeometryEffect, etc.]
**Character**: [How it feels — snappy, playful, elegant, subtle, dramatic]
**Complexity**: [Low / Medium / High — implementation and maintenance cost]
**iOS floor**: [Minimum iOS version required]

その後、情報に基づく理由を添えて推奨案を提示します。推奨案では、次の点を考慮します。

• デプロイメントターゲットに対するAPIの利用可否
• 複雑さの予算。アニメーションがアプリを象徴する重要な場面でない限り、シンプルなほうが適切です
• システムがすでに対応しているかどうか。カスタム実装より、システムが提供するモーションを優先します
• アプリ既存のモーション表現との一貫性
• キャンセル可能性。ユーザーはアニメーションを中断したり、スキップしたりできますか。「ユーザーが何かをする前にアニメーションの完了を待たせてはいけません」（Apple HIG）
• アクセシビリティ（視差効果を減らす設定に応じて、適切に簡素化できますか）
• マルチモーダルなフィードバック。アニメーションだけを唯一の合図にしてはいけません。「触覚や音声などの代替手段も使用して、視覚的なフィードバックを補ってください」（Apple HIG）

ステップ 3：アニメーション仕様をまとめる

ユーザーがアプローチを選択（または推奨案を承認）したら、構造化された仕様を作成します。この仕様は、設計と実装の間の取り決めです。曖昧さなくコードを書けるよう、必要な情報をすべて含めてください。

アニメーション仕様の形式

# Animation Spec: [Name]

## Overview
[1-2 sentences: what this animation does and why it exists]

## Trigger
- **Event**: [What initiates the animation — tap, state change, appear, gesture, etc.]
- **Direction**: [Forward / Reverse / Bidirectional]

## Motion Design

### Properties
| Property | From | To | Curve | Duration |
|----------|------|----|-------|----------|
| opacity | 0 | 1 | .easeOut | 0.25s |
| scale | 0.8 | 1.0 | .spring(duration: 0.5, bounce: 0.3) | — |
| offset.y | 20 | 0 | .spring(duration: 0.5, bounce: 0.3) | — |

### Timing
- **Total duration**: [end-to-end time]
- **Stagger**: [if multiple elements, delay between each]
- **Interruption**: [What happens if triggered again mid-animation — cancel, reverse, queue]

### Gesture Binding (if interactive)
- **Gesture type**: [drag, long press, rotation, magnification]
- **Progress mapping**: [How gesture progress maps to animation progress]
- **Threshold**: [When the animation commits vs. cancels]
- **Velocity handling**: [How release velocity affects completion]

## Accessibility & Multimodal Feedback
- **Reduce Motion**: [What happens — crossfade, instant, simplified version]
- **VoiceOver**: [Any announcement needed for the state change]
- **Haptics**: [Which sensoryFeedback type pairs with this animation — .impact, .selection, .success, etc.]
- **Audio**: [Optional sound cue if the state change is important enough]
- **Dynamic Type**: [Does layout shift affect the animation?]

## Implementation Notes
- **Recommended API**: [SwiftUI withAnimation, KeyframeAnimator, PhaseAnimator, matchedGeometryEffect, UIViewPropertyAnimator, etc.]
- **State model**: [What @State/@Binding drives this animation]
- **Extractable component**: [Yes/No — should this be a reusable ViewModifier or View?]

アニメーションのカテゴリー

設計時には、次のカテゴリーを念頭に置いてください。それぞれ、タイミング、イージング、目的について異なる期待があります。

ナビゲーションとシーンの切り替え

画面間の移動です。ユーザーは空間的な一貫性を期待します。どこから来て、どこへ向かうのか。素早く、確信を持って操作できる動きにします。

• ヒーロー要素を使ったプッシュ／ポップ（matchedGeometryEffect、navigationTransition(.zoom)）
• 全画面表示とシート（カスタムのTransitionプロトコル）
• タブの切り替え（クロスフェード、スライド、またはマッチドジオメトリー）
• オンボーディングのフロー（段階的に表示するページ形式）

タイミング：0.3～0.5s。イージング：スプリングベース（.snappyまたは.smooth）。中断時：戻るジェスチャーに適切に対応する必要があります。

マイクロインタラクション

ユーザーの操作に対する、小さく即時のフィードバックです。AppleのHIGでは、簡潔さが重視されています。「アニメーションによるフィードバックが短く正確であれば、軽快で目立ちにくく感じられ、目立つアニメーションよりも効果的に情報を伝えられることがよくあります。」操作の妨げにならない、ほぼ瞬時の反応にしてください。頻繁に行われる操作では、カスタムの動きを追加する前に、システム標準のアニメーションで十分かどうかを慎重に検討してください。

• ボタンの押下状態（スケール＋触覚フィードバック）
• トグル／スイッチのアニメーション
• いいね／お気に入り／ブックマークへの反応
• 引っ張って更新する際のインジケーター
• テキストフィールドのフォーカス切り替え
• スワイプアクションの表示

タイミング：0.1～0.3s。イージング：.snappyまたは.spring(duration: 0.2, bounce: 0.4)。必ずsensoryFeedbackと組み合わせます。触覚フィードバックは視覚的なフィードバックを強め、アニメーションが見えないユーザーにも情報を伝えます。

コンテンツの切り替え

ビュー内でデータが変化する際のアニメーションです。数値の更新、コンテンツの切り替え、リストの並べ替えなどが該当します。

• 数値テキストの切り替え（.contentTransition(.numericText)）
• 画像のクロスフェード
• リスト項目の挿入／削除
• スケルトン表示からコンテンツへの切り替え
• エラー／空／読み込み完了状態の切り替え

タイミング：0.2～0.35s。イージング：.smoothまたは.easeInOut。変化するデータに紐付けたanimation(_:value:)を使います。

ジェスチャー駆動のアニメーション

ユーザーが進行を直接制御するインタラクティブなアニメーションです。指と物理的につながっているように感じられる必要があります。遅延やずれがあってはいけません。

• カードの解除（スワイプして削除）
• ドロワー／シートのドラッグ
• ピンチによる拡大縮小
• 回転操作
• スクロールに連動する視差（scrollTransition）

完了時にはスプリングベースの動きが不可欠です。指を離したときの速度を追跡します。UIKitではUIViewPropertyAnimatorを、SwiftUIではGestureStateとスプリングを使います。

読み込みと進行状況

待機中であることや進行状況を伝えます。気が散らない範囲で、動きを感じられるようにします。

• スケルトン画面（グラデーションマスクによるシマー効果）
• 不定進行のスピナー（SF Symbolの.symbolEffect(.pulse)）
• 確定進行のプログレス表示（アニメーション付きのバー／リング）
• コンテンツのプレースホルダーのパルス（PhaseAnimator）

ループするアニメーションは軽量に保ちます。連続して実行されるため、バッテリーを消耗したり、動作の引っかかりを起こしたりしてはいけません。

アンビエントと装飾

雰囲気を演出する背景の動きです。使いすぎやすいため、控えめに使用します。

• アニメーション付きグラデーション（タイマー駆動でポイントが移動するMeshGradient）
• 浮遊するパーティクル効果
• デバイスの傾きに応じた控えめな視差効果
• 背景のぼかしの切り替え

Reduce Motionが有効な場合は、必ず無効化するか、動きを簡略化します。パフォーマンスを改善する際に、最初に削る対象です。

原則

1. 見栄えより目的 — 動きを加える理由を説明できないなら、動かすべきではありません。AppleのHIG：「動きを加えること自体を目的に、動きを加えてはいけません。」
2. まずシステムを活用 — 多くのシステムコンポーネントには、すでに動きが組み込まれています（Liquid Glass、ナビゲーションのトランジション、シート、SF Symbolのエフェクト）。カスタムの動きを設計する前に、システムで対応できるか確認してください。カスタムアニメーションはシステムの動きを重複させるのではなく、その不足を補うものです。
3. 華やかさより簡潔さ — AppleのHIG：「フィードバックアニメーションは簡潔で正確なものを目指してください。」短いアニメーションのほうが、目立つアニメーションよりも効果的に情報を伝えます。アクションに結びついた簡潔な反応は、凝った一連の動きよりも優れています。
4. カーブよりスプリング — スプリングアニメーションは物理的な動きを感じさせます。特別な理由がない限り、ベジェ曲線ではなく、duration と bounce のパラメーターを使ってください。
5. 視差効果を減らす設定への対応は必須 — すべてのアニメーション仕様に、視差効果を減らす設定が有効な場合の代替手段を含めてください。AppleのHIG：「動きを選択可能にしてください。すべての人がアプリの動きを体験したい、または体験できるわけではありません。」これは、重要な情報を伝える唯一の手段としてアニメーションを使ってはいけないということでもあります。
6. マルチモーダルなフィードバック — 適切な場合は、触覚フィードバック（.sensoryFeedback）や音声もアニメーションと組み合わせてください。重要な状態の変化をアニメーションだけで伝えるべきではありません。
7. キャンセルはユーザーの権利 — AppleのHIG：「特にアニメーションを何度も体験しなければならない場合、アニメーションが終わるまで何もできない状態にしてはいけません。」すべてのアニメーションは中断できるようにしてください。
8. 空間的な動きに沿ったフィードバック — 動きはユーザーのジェスチャと期待に沿うべきです。ビューを下にスライドした人は、横ではなく下にスライドして閉じることを期待します。空間的な感覚に反するフィードバックは、ユーザーを戸惑わせます。
9. 速さが信頼を生む — 0.3秒未満のアニメーションは反応がよく感じられます。アプリを象徴する特別な演出でない限り、0.5秒を超えると遅く感じられます。迷ったら、速くしてください。
10. 一貫性が積み重なる — 類似する操作には、同じスプリングパラメーターを使ってください。一貫したモーションの表現によって、アプリ全体にまとまりが生まれます。少数のタイミングプリセットを定義し、繰り返し使ってください。