platform-conventions

プラットフォームの慣例

iOS Human Interface Guidelines と Material Design、ならびにプラットフォームネイティブな製品デザインとクロスプラットフォームの製品デザインの間にあるトレードオフに精通しています。

できること

プラットフォームで必須とされる UI パターンを特定し、iOS と Android の重要な違いを整理して、各プラットフォームの慣例に従うべき場合と、統一されたクロスプラットフォームデザインが適切な場合をチームが判断できるよう支援します。

プラットフォームの慣例が重要な理由

ユーザーは時間の大半を OS とネイティブアプリで過ごします。そのため、ナビゲーション、コントロール、操作パターンについて強い筋肉の記憶が形成されます。明確な理由なく製品がプラットフォームの慣例から外れると、ユーザーは製品を使うことよりも、製品の使い方を理解することに認知的な負荷を費やすことになります。

主な違い：iOS（HIG）と Android（Material Design 3）

ナビゲーション

パターン	iOS	Android
戻るナビゲーション	左端から右にスワイプ、または左上の戻るボタン	システムの戻るジェスチャー（左右どちらかの端からスワイプ）または予測型の戻る操作、アプリバーの戻る矢印
主な構造	画面下部のタブバー、iPad ではサイドバー	画面下部のナビゲーションバー、またはナビゲーションドロワー（ハンバーガーメニュー）
ナビゲーション履歴	スタック方式。各タブに独自のスタックがあります	アプリ全体で単一の戻るスタックを使用します。デフォルトではタブごとに独立した履歴は保持されません
下部ナビゲーション	最大 5 個のタブ。ラベルは必須ではありません	3～5 個のタブ。ラベルが必要です

デザイン上の留意点：iOS ユーザーは左端からのスワイプで常に戻れることを期待するため、そのジェスチャー領域を確保してください。Android ではシステムの戻るジェスチャーがこの操作を担うため、競合することなく、アプリ内の左端からのスワイプをドロワーに使用できます。

コントロールとコンポーネント

コンポーネント	iOS の慣例	Android（Material 3）の慣例
トグルスイッチ	UISwitch — ピル型で、リスト内では右寄せ	Switch — サムとトラックで構成され、インラインまたはリスト内に表示できます
破壊的操作の確認	画面下部のアクションシートに、赤色の破壊的操作を表示	テキストボタン付きダイアログ。破壊的操作には赤色／エラーのトーンを使用
日付／時刻ピッカー	ホイールピッカー、またはインラインのカレンダー	テキスト入力への切り替えが可能なカレンダー
選択メニュー	ホイールピッカーまたはアクションシート	展開式ドロップダウンまたはモーダルのボトムシート
プライマリボタン	塗りつぶしの長方形。フォーム内では全幅	塗りつぶしボタン（M3 ではデフォルトで角丸）
フローティングアクション	慣例ではありません。状況に応じたボタンを使用	FAB — 主要な画面操作として右下に配置
引っ張って更新	ネイティブの UIRefreshControl	SwipeRefreshLayout — ジェスチャーは同じで、見た目は異なります

タイポグラフィ

属性	iOS	Android
システムフォント	SF Pro（テキスト）／SF Compact（時計）	Roboto／Google Sans
Dynamic Type	必須 — ユーザーはシステム全体のテキストサイズを調整できます	スケーラブルピクセル（sp）— システムのフォントスケールに従う必要があります
文字スタイル	iOS のテキストスタイル（Large Title、Title 1–3、Body など）	Material の文字スケール（Display、Headline、Title、Body、Label）

どちらのプラットフォームでも、アプリはユーザーが設定したシステムのフォントサイズを尊重する必要があります。拡大縮小されない固定のポイントサイズを使用することは、両プラットフォームでアクセシビリティ上の問題となります。

操作とジェスチャーの慣例

ジェスチャー	iOS の動作	Android の動作
スワイプして削除	テーブルビューで標準	スワイプして閉じる／アーカイブする（状況による）
長押し	Peek／コンテキストメニュー（iOS 13 以降のコンテキストメニュー）	コンテキストアクションモード。長押しで選択
引っ張って更新	標準	標準
ピンチして拡大	マップや画像で標準	標準
戻るスワイプ	戻る操作専用 — 常に前の画面に戻ります	予測型の戻るジェスチャー。アプリはプレビューを表示するよう設定できます

ビジュアルとアイコン

領域	iOS	Android
アイコンライブラリ	SF Symbols（数千種類、ウェイト可変、自動スケーリング）	Material Symbols（丸みのあるスタイル、アウトライン、シャープなスタイル）
角の丸み	大きめの「スクワークル」曲線（スーパー楕円）	中程度 — Material 3 ではコンポーネントに目立つ丸みを使用
システムカラー	ダークモード／ライトモードに自動で適応するダイナミックカラー	Material You のダイナミックカラー — 壁紙から生成
モーダル表示	下からスライドして表示されるシート。つまみ付き	ボトムシート（標準またはモーダル）、または全画面ダイアログ

クロスプラットフォームのデザイン方針

各プラットフォームのガイドラインに厳密に従う場合

• プラットフォームへの習熟度が品質の重要な指標となる、ネイティブまたはネイティブに近いアプリ（バンキング、ヘルスケア、ユーティリティアプリ）
• OS 機能（共有シート、ウィジェット、Siri／Google Assistant）と深く連携するアプリ
• そのプラットフォームに慣れたパワーユーザーが多いアプリ

統一したデザインが適切な場合

• プラットフォーム間で機能の同等性が高く、デザインの一貫性によって保守コストを削減できる製品
• デバイス間の継続性が重要な製品（例：ユーザーが iPhone、Android、ウェブの間で切り替えて利用する）
• ユーザーが OS の操作パターンではなく、主に製品独自のデザインシステムを使う B2B ツール

ハイブリッドアプローチ

ほとんどのクロスプラットフォーム製品では、統一されたビジュアル言語とコンポーネント言語を採用しつつ、ナビゲーション（システムレベルの慣例）、システムコントロール、ジェスチャーの競合にはプラットフォーム固有の調整を加える中間的なアプローチが取られます。製品は独自の見た目を保ちながら、OS の操作に従います。

避けるべきこと

• スワイプアップ操作と競合するジェスチャーナビゲーションを使う Android で、下部タブバーを使用しないでください
• iOS のスワイプバックジェスチャーを無効にしないでください — ジェスチャーを実行しても何も起きなければ、ユーザーは戸惑い、信頼を失います
• 主要な意思決定パターンとして、Android で iOS のアクションシートを使ったり、iOS で Android のダイアログを使ったりしないでください
• どちらのプラットフォームでも Dynamic Type／SP スケーリングを無視しないでください — テキストサイズの固定はアクセシビリティ上の問題です
• 正当な理由なく FAB パターンを iOS に持ち込まないでください — iOS にはネイティブの前例がありません

ベストプラクティス

• 大きなデザインフェーズの開始前に、各プラットフォームの最新ガイドラインを確認してください。iOS HIG と Material 3 はどちらも頻繁に更新されます
• 解決策を提案する前に、設計対象のインタラクションについて、各プラットフォームのネイティブアプリを調査してください
• コンポーネント対応表を作成し、デザインシステム、iOS、Android でそれぞれの要素がどう呼ばれるかを記録してください
• プラットフォームごとに実機でテストしてください — シミュレーターでの動作やジェスチャーの処理は、実機とは異なります
• プラットフォーム固有のパターンに迷った場合は、OS に標準搭載されているものを使ってください。すでにテストされ、ユーザーにも馴染みがあります