mcpField
A
axiom-hig-ref

axiom-hig-ref

github.com/charleswiltgenデザイン・UI1.2k207 回インストール今日更新
リポジトリ

axiom-hig-ref について

Apple プラットフォーム向けのデザインを行う開発者やデザイナー向けの Human Interface Guidelines 参照スキルです。画面設計の原則、色、タイポグラフィ、形状、マテリアルをまとめ、プラットフォームに沿った判断を支援します。

主な機能

  1. 01Clarity、Consistency、Deference の原則
  2. 02セマンティックカラーと外観の指針
  3. 03システムフォントと Dynamic Type の指針
  4. 04形状、ジオメトリ、マテリアルの参照

活用シーン

  1. 01Apple の設計原則に沿った画面の確認
  2. 02ライト・ダークモード用のセマンティックカラー選定
  3. 03Dynamic Type 対応のタイポグラフィ設計
  4. 04入れ子状の画面に使う形状とマテリアルの設計

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/charleswiltgen/axiom --skill axiom-hig-ref

インストール後、Claude Code で/axiom-hig-refを入力して読み込まれたか確認します。

詳細

Apple Human Interface Guidelines — 包括的リファレンス

概要

Human Interface Guidelines(HIG)はAppleのデザイン哲学を定義し、すべてのAppleデバイスで直感的かつアクセシブルで、各プラットフォームに適した体験を作成するための具体的な指針を示します。

3つの基本原則

すべてのデザイン上の決定は、次の原則を支えるものである必要があります。

1. 明瞭さ コンテンツが最も重要です。インターフェイスの要素はコンテンツを引き立てるべきであり、競い合うべきではありません。すべての要素に目的があり、不要な複雑さは取り除かれ、ユーザーは詳細な説明がなくても何ができるかをすぐに理解できる必要があります。

2. 一貫性 アプリは標準的なUI要素と、なじみのあるパターンを使用します。ナビゲーションはプラットフォームの慣習に従い、ジェスチャは期待どおりに機能し、コンポーネントは想定される場所に表示されます。この親しみやすさによって認知負荷が軽減されます。

3. 控えめさ UIは重要なコンテンツから注意をそらすべきではありません。控えめな背景を使い、必要のないときはナビゲーションを後退させ、ブランディングを控えめにして、コンテンツを主役にしましょう。

Apple HIGより:「控えめさによって、周囲の視覚要素がコンテンツと競い合うことなく、コンテンツを際立たせることで、アプリを美しくできます。」

デザインシステムの哲学

WWDC25より:「体系的なアプローチとは、最も小さなコントロールから最も大きなサーフェスまで、すべての要素が全体との関係の中で考慮されるよう、あらゆるレベルで意図を持ってデザインすることです。」

関連スキル
  • すばやい判断やチェックリストには axiom-hig を使用します
  • iOS 26のマテリアル実装には axiom-liquid-glass を使用します
  • iOS 26アプリ全体への導入には axiom-liquid-glass-ref を使用します
  • アクセシビリティのトラブルシューティングには axiom-accessibility-diag を使用します

カラーシステム

セマンティックカラーの説明

色をハードコードするのではなく、見た目ではなく色の目的を表すセマンティックカラーを使用します。セマンティックカラーはライト/ダークモードやアクセシビリティ設定に自動的に適応します。

WWDC19からの重要なポイント:「ダークモードは、すべてが裏返しになるのではなく、照明を暗くした状態だと考えてください。」色は単純に反転するわけではありません。テーブルの行の背景は、どちらのモードでも明るくなります。

ラベルカラー(前景コンテンツ)

テキストやシンボルには4段階のセマンティックラベルカラーがあり、段階的に目立たなくなります。

スタイルセマンティックカラー用途
.primarylabelタイトル、最も目立つテキスト
.secondarysecondaryLabelサブタイトル、やや目立たないテキスト
.tertiarytertiaryLabelプレースホルダーテキスト
.quaternaryquaternaryLabel無効状態のテキスト
Text("Title").foregroundStyle(.primary)    // Black in Light, white in Dark
Text("Subtitle").foregroundStyle(.secondary)
背景色(プライマリ → ターシャリ)

背景色には、非グループ化(標準的なリスト)とグループ化(iOSの「設定」スタイル)の2種類があります。

レベル非グループ化グループ化
プライマリ.systemBackground.systemGroupedBackground
セカンダリ.secondarySystemBackground.secondarySystemGroupedBackground
ターシャリ.tertiarySystemBackground.tertiarySystemGroupedBackground

非グループ化:ライトモードでは純白、ダークモードでは純黒です。グループ化:ライトモードではライトグレー、ダークモードではダークグレーです。

// Standard list → ungrouped backgrounds
List { Text("Item") }
    .background(Color(.systemBackground))

// Settings-style list → grouped backgrounds
List { Section("Section") { Text("Item") } }
    .listStyle(.grouped)
ベース背景と浮き上がった背景

インターフェイスを重ねるための背景色には、実際には2種類あります。

  • ベースセット: 背景にあるアプリ/インターフェイスに使用します
  • 浮き上がったセット: 前面にあるアプリ/インターフェイスに使用します

重要な理由:

ライトモードでは、シンプルなドロップシャドウで視覚的な分離を作れます。ダークモードではドロップシャドウの効果が弱くなるため、システムは浮き上がったコンテンツに明るい色を使用します。

例: iPadのマルチタスク:

  • メールアプリのみ → ベースカラーセット
  • スライドオーバーで表示する連絡先 → 浮き上がったカラー(より明るく、目立つ)
  • 並べて表示する場合 → 分割線の周囲にコントラストをつけるため、両方に浮き上がったカラーを使用
  • メール作成シート → オーバーレイで暗くした浮き上がったカラー

重要: 濃い色の中には、浮き上がった状態ではコントラストが不十分になるものがあります。デザインは必ず浮き上がった状態でもテストしてください。半不透明の塗りつぶし色や区切り線の色は、適切に適応します。

Tint Colors(動的な適応)

Tint Colors は動的で、ライトモードとダークモード用のバリエーションがあります。

// Tint color automatically adapts
Button("Primary Action") {
    // action
}
.tint(.blue)
// Gets lighter in Dark Mode, darker in Light Mode

カスタムの Tint Colors: カスタムの Tint Colors を作成する際は、どちらのモードでも適切に表示される色を選択してください。コントラスト計算ツールを使い、コントラスト比が4.5:1 以上になるようにします。ライトモードで適切に見える色でも、ダークモードではコントラストが不十分な場合があります。

Fill Colors(半透明)

Fill Colors は、変化する背景に対して適切なコントラストを保てるよう、半透明になっています。

// System fill colors
Color(.systemFill)
Color(.secondarySystemFill)
Color(.tertiarySystemFill)
Color(.quaternarySystemFill)

使用する場面: 変化する背景の上に表示する必要があるコントロール、ボタン、インタラクティブ要素。

Separator Colors
// Standard separator (semi-transparent)
Color(.separator)

// Opaque separator
Color(.opaqueSeparator)

透明にすると望ましくない結果になる場合(たとえば、半透明の色が重なることで目の錯覚が生じる、交差するグリッド線など)には、不透明な区切り線を使用します。

恒久的なダーク背景を使用する場面

Apple の明確な指針:

「まれなケースでは、インターフェイスにダーク表示のみを使用することを検討してください。たとえば、没入感のあるメディア表示を可能にするアプリでは、UI が背景に溶け込み、メディアに集中しやすくなる恒久的なダーク表示が適している場合があります。」

Apple のアプリの例:

アプリ背景理由
Musicダークアルバムアートを視覚的な中心にするため
Photosダーク画像が主役のコンテンツであるため
Clockダーク夜間の使用と計器のような印象のため
Stocksダークデータの視覚化とチャートのため
Cameraダーク撮影中の注意散漫を減らすため

その他すべてのアプリ: システム背景を使用して、ライトモードとダークモードの両方をサポートします。

カスタムカラーの作成

カスタムカラーが必要な場合:

  1. Assets.xcassets を開く
  2. Color Set を追加する
  3. バリエーションを設定する:
    • ライトモードの色
    • ダークモードの色
    • 高コントラストのライト(任意ですが推奨)
    • 高コントラストのダーク(任意ですが推奨)
// Use custom color from asset catalog
Color("BrandAccent")
// Automatically uses correct variant

タイポグラフィ

システムフォント

San Francisco(SF): システムのサンセリフフォントファミリーです。

  • SF Pro:一般用途
  • SF Compact:watchOS およびスペースが限られたレイアウト
  • SF Mono:コードおよび等幅テキスト
  • SF Rounded:柔らかく親しみやすい印象
  • ウェイト:Ultralight、Thin、Light、Regular、Medium、Semibold、Bold、Heavy、Black

New York(NY): エディトリアルコンテンツ向けのシステムセリフフォントファミリーです。

どちらも可変フォントとして利用でき、ウェイトをシームレスに切り替えられます。

フォントウェイトの推奨事項

Apple HIG より:「ライトウェイトのフォントは避けてください。Ultralight、Thin、Light ではなく、Regular、Medium、Semibold、Bold のウェイトを優先してください。」

理由: ライトウェイトは、特に小さいサイズや明るい照明下で、また視覚に障がいのあるユーザーにとって、読みやすさに問題が生じます。

階層:

// Headers - Bold weight for prominence
Text("Header")
    .font(.title.weight(.bold))

// Subheaders - Semibold
Text("Subheader")
    .font(.title2.weight(.semibold))

// Body - Regular or Medium
Text("Body text")
    .font(.body)

// Captions - Regular (never Light)
Text("Caption")
    .font(.caption)
階層を示すテキストスタイル

組み込みのテキストスタイルを使い、階層と Dynamic Type のサポートを自動化します。

.font(.largeTitle)  .font(.title)       .font(.title2)
.font(.title3)      .font(.headline)    .font(.body)
.font(.callout)     .font(.subheadline) .font(.footnote)
.font(.caption)     .font(.caption2)

すべてのテキストスタイルは Dynamic Type に合わせて自動的に拡大縮小されます。

Dynamic Type のサポート

要件: アプリは、テキストを少なくとも 200%(iOS、iPadOS)または 140%(watchOS)まで拡大できるようにする必要があります。

実装:

// ✅ CORRECT - Scales automatically
Text("Hello")
    .font(.body)

// ❌ WRONG - Fixed size, doesn't scale
Text("Hello")
    .font(.system(size: 17))

レイアウトに関する考慮事項:

  • サイズが大きい場合は、複数列のレイアウトを減らす
  • テキストの切り詰めを最小限に抑える
  • 大きなサイズでは、インラインレイアウトではなく積み重ねたレイアウトを使う
  • サイズにかかわらず、一貫した情報の階層を維持する

すべてのコンテンツが同じように拡大するわけではありません: ユーザーが実際に重視するものを優先してください。タブのタイトルなどの二次的な要素は、主要なコンテンツほど大きくしないようにします。

カスタムフォント

カスタムフォントを使用する場合:

  • さまざまな距離や環境で読みやすいことを確認する
  • Dynamic Type のサポートを実装する
  • アクセシビリティ設定の「文字を太くする」に対応する
  • すべてのテキストサイズでテストする
  • アクセシビリティのため、システムフォントと同様の動作にする

カスタムフォントが細い場合: 大文字のラテン文字と組み合わせるときは、サイズを約 2 ポイント大きくします。

行送り(行間)

広めの行送り: 幅の広い段組み(次の行を追いやすくなります) 狭めの行送り: 高さが限られている場合(3 行以上では避けてください)

// Adjust leading for specific layouts
Text("Long content...")
    .lineSpacing(8) // Add space between lines

形状とジオメトリ

3種類のシェイプ(iOS 26)

WWDC25より:「シェイプの組み合わせには、同心性によって生まれる穏やかな幾何学的な調和があります。共通の中心を軸に半径と余白を揃えることで、シェイプ同士を自然に入れ子にできます。」

1. 固定シェイプ

サイズにかかわらず、角の半径が一定です。

RoundedRectangle(cornerRadius: 12)

使用する場合: 特定の、変化しない角の半径が必要なとき。

2. カプセル

半径はコンテナーの高さの半分です。

Capsule()

使用する場合: 丸みのある端を保ちながら、コンテンツに合わせて形状を変えるシェイプが必要なとき。ボタン、ピル、コントロールに最適です。

iOS 26のさまざまな場所で使用されています: スライダー、スイッチ、グループ化されたテーブルビュー、タブバー、ナビゲーションバー。

3. 同心シェイプ

親の半径からパディングを差し引いて半径を計算します。

.containerRelativeShape(.roundedRectangle)

使用する場合: コンテナー内にシェイプを入れ子にして、視覚的な調和を保つとき。

同心性の原則

ハードウェアとソフトウェアの調和: Appleのハードウェアには、一貫したベゼルの曲率があります。同じ精密さがUIにも取り入れられ、曲率、サイズ、比率を揃えることで、手に持つものと目にするものの間に統一感のあるリズムを生み出しています。

同心性の例:

Window (rounded corners)
  ├─ Sheet (concentric to window)
  │   ├─ Card (concentric to sheet)
  │   │   └─ Button (concentric to card)
プラットフォームごとのガイダンス

iOS:

  • ボタン、スイッチ、グループ化されたリストにはカプセル
  • タッチ操作に適したレイアウトで、階層とフォーカスを生み出します

macOS:

  • Mini、Small、Mediumコントロール → 角丸長方形(密度の高いレイアウト、インスペクターパネル)
  • Large、X-Largeコントロール → カプセル(広々とした領域、Liquid Glassによる強調)
光学的なセンタリング

光学的なバランスを保つため、ビューは次のように配置されます。

  • 適切な場合は、数学的に中央に配置します
  • 光学的な重心に応じて、わずかにオフセットします

例: 非対称のアイコンでは、幾何学的な中央配置ではなく、光学的に中央に配置するためのパディング調整が必要になることがあります。


マテリアルと奥行き

標準マテリアル

マテリアルを使うと背景のコンテンツが透けて見え、視覚的な奥行きと階層が生まれます。

4種類の厚さ
  1. 極薄 — 分離感を最小限に抑え、コンテンツをはっきり見せます
  2. 薄 — より軽やかな操作に適しています
  3. 標準 — デフォルトで、多くの状況に適しています
  4. 厚 — 背景から最も強く分離します

厚さの選び方:

  • コンテンツにより高いコントラストが必要 → 厚めのマテリアル
  • シンプルなコンテンツ → 薄い/極薄のマテリアル
// Apply material
.background(.ultraThinMaterial)
.background(.thinMaterial)
.background(.regularMaterial)
.background(.thickMaterial)
マテリアルとビビッド効果

重要な原則: 読みやすさを確保するため、マテリアルの上にはビビッドな色を使います。不透明な色は、背景の状況によって濁って見えることがあります。ビビッド効果を使えば、背景にかかわらずコントラストを保てます。

// Vibrant text on material
VStack {
    Text("Primary")
        .foregroundStyle(.primary) // Vibrant
    Text("Secondary")
        .foregroundStyle(.secondary) // Vibrant
}
.background(.regularMaterial)
Liquid Glass(iOS 26以降)

目的: コンテンツの上に浮かぶ、コントロールとナビゲーションのための独立した機能レイヤーを作ります。

2つのバリエーション:

  1. 標準のLiquid Glass

    • デフォルト。95%のケースで使用します
    • 視覚効果と適応効果を完全に備えています
    • どのような状況でも読みやすさを確保します
    • どのような背景にも対応します
  2. クリアLiquid Glass

    • 透明度が高い
    • 適応動作はありません
    • 視覚的に豊かな背景(写真、動画)の上にあるコンポーネントにのみ使用します
    • 読みやすさを確保するには、減光レイヤーが必要です

モーダルとシート(iOS 26以降): Xcode 26では、シート、アラート、ポップオーバーにLiquid Glassが自動的に適用されます。カスタムの.presentationBackground()やUIBlurEffectによる背景は削除してください。マテリアル、同心の角の半径、モーフィングトランジションはシステムが処理します。モーダルコンテンツの背景には、シート本体にLiquid Glassを使わず、強調されたセマンティックカラーを使用します。

関連項目: シート、アラート、ポップオーバー、モーフィングトランジションを含むLiquid Glassの実装パターン全般については、axiom-liquid-glass-refを参照してください。判断フローチャートについては、axiom-liquid-glassを参照してください。


レイアウトの原則

視覚的な階層

相対的な重要度が伝わるように項目を配置します:

  • 重要なコンテンツ → 上部と左側
  • 二次的なコンテンツ → 下部または右側
  • 三次的なコンテンツ → 別のビュー、または段階的な開示

Apple HIGより:「重要な情報に十分なスペースを与え、重要でない詳細で覆い隠さないようにして、必要な情報を見つけやすくします。」

グループ化と整理

関連する項目は、次の方法でグループ化します。

  • ネガティブスペース(余白)
  • 色や素材
  • 区切り線

Liquid Glass の素材とスクロール端のエフェクトを使い、コンテンツとコントロールが明確に区別されるようにします。

画面端までコンテンツを広げる

背景やアートワークをディスプレイの端まで広げて、「画面またはウインドウを埋めるようにコンテンツを拡張」します。

背景拡張ビュー: コンテンツがウインドウ全体に自然には広がらない場合に使用します。

// Content extends to edges
VStack {
    FullWidthImage()
        .ignoresSafeArea() // Extends to screen edges
}
セーフエリアとレイアウトガイド

セーフエリア: 次の要素に遮られない長方形の領域です。

  • ステータスバー
  • ナビゲーションバー
  • タブバー
  • ツールバー
  • デバイスの機能(Dynamic Island、ノッチ、ホームインジケータ)

レイアウトガイド: 次の要素を使って、コンテンツの配置と間隔を定める長方形の領域です。

  • 定義済みのマージン
  • テキスト幅の最適化
  • 読みやすい幅の制約

重要な原則:「各プラットフォームの主要なディスプレイ機能とシステム機能を尊重します。」

// Respect safe areas
VStack {
    Text("Content")
}
.safeAreaInset(edge: .bottom) {
    BottomBar()
}
コンポーネントの整列

「コンポーネントを互いに整列させ、スキャンしやすくします。」

グリッドに沿った整列:

  • テキストのベースラインを揃える
  • コントロールを共通のグリッドに沿って配置する
  • 一貫性のあるリズミカルな間隔にする
適応性に関する要件

次のようなレイアウトを設計します。

  • 「一貫性を保ちながら、状況の変化に柔軟に適応する」
  • Dynamic Type による文字サイズの変更に対応する
  • 複数のデバイス、向き、ローカライズに対応する
  • さまざまな画面サイズ、解像度、システム機能を考慮する

アクセシビリティ

視覚に関するアクセシビリティ
テキストと読みやすさ

要件:

  • テキストを少なくとも 200%(watchOS では 140%)まで拡大できるようにする
  • システム全体の文字調整に Dynamic Type を実装する
  • 読みやすさを高めるフォントの太さを使う(カスタムフォントでは Light のウェイトを避ける)
色のコントラスト

WCAG レベル AA の基準:

  • 通常のテキスト(14pt 以上):最低 4.5:1
  • 小さいテキスト(14pt 未満):7:1 を推奨
  • 大きいテキスト(通常の 18pt 以上、太字の 14pt 以上):3:1 で許容

実装:

// ✅ Use semantic colors (automatic contrast)
Text("Label").foregroundStyle(.primary)

// ❌ Custom colors may fail contrast
Text("Label").foregroundStyle(.gray) // Check with calculator

ハイコントラストモード: アクセシビリティ設定の「コントラストを上げる」が有効な場合は、よりコントラストの高い配色を提供します。

ライトモードとダークモードの両方でテストします。

色に関する配慮

重要: 色覚に障害のあるユーザーにも対応できるよう、「色だけに頼らず情報を伝えます」。

解決策:

  • 色とともに異なる形状やアイコンを使う
  • テキストラベルを追加する
  • アクセシビリティに配慮したバリエーションを持つシステム定義色を使用する
  • 色覚シミュレーターでテストする

例:

// ❌ Only color indicates status
Circle().fill(isActive ? .green : .red)

// ✅ Shape + color
HStack {
    Image(systemName: isActive ? "checkmark.circle.fill" : "xmark.circle.fill")
    Text(isActive ? "Active" : "Inactive")
}
.foregroundStyle(isActive ? .green : .red)
スクリーンリーダー

VoiceOver のアクセシビリティに対応するため、インターフェースとコンテンツを説明します。

Button {
    share()
} label: {
    Image(systemName: "square.and.arrow.up")
}
.accessibilityLabel("Share")
聴覚に関するアクセシビリティ
メディアの代替手段

動画や音声のコンテンツには、次のものを提供します。

  • 会話のキャプション
  • 字幕
  • 映像のみで伝える情報の音声解説
  • 長尺メディアの文字起こし
音声の合図

音声による合図には、次のものを組み合わせます。

  • 触覚フィードバック
  • 視覚的なインジケータ
身体の動きに関するアクセシビリティ

タッチターゲット:

  • 最小サイズ:44x44 ポイント
  • 間隔:コントロールの周囲に 12〜24 ポイントのパディング

ジェスチャ:

  • シンプルなジェスチャを使う
  • 代替手段を用意する(ジェスチャと併用できるボタンなど)
  • Voice Control に対応する
  • キーボードナビゲーションを有効にする

支援技術:

  • VoiceOver
  • Switch Control
  • フルキーボードアクセス
認知に関するアクセシビリティ
インタラクション設計
  • 「操作をシンプルで直感的にする」
  • 時間経過で自動的に消えるビューを避ける
  • コントロールなしで音声や動画が自動再生されないようにする
モーションと視覚エフェクト

「視差効果を減らす」を尊重します。

  • アニメーションを最小限にする
  • 過度な点滅を避ける
  • 「点滅する光を暗くする」に対応する
  • バウンスエフェクトを減らす
  • Z 軸方向の奥行きの変化を最小限にする
// Check Reduce Motion setting
@Environment(\.accessibilityReduceMotion) var reduceMotion

var body: some View {
    content
        .animation(reduceMotion ? nil : .spring(), value: isExpanded)
}
ゲームでの配慮

調整可能な難易度を用意します。

visionOS 固有の要件

快適さを優先します。

  • 水平レイアウトを維持する
  • アニメーションの速度を落とす
  • ヘッドアンカー付きコンテンツを避ける(支援技術の使用を妨げるため)

モーションとアニメーション

基本原則

目的を持ったアニメーション:「体験を損なわず、それを支えるために、目的を持って動きを加えます。」

気を散らせたり、不快感を与えたりする不必要なアニメーションは避けてください。動きはインターフェースを支配するのではなく、より良いものにする必要があります。

アクセシビリティを最優先

動きをオプションにします。視覚的なフィードバックを触覚フィードバックや音声で補い、重要な情報を伝えます。これにより、動きに関する好みにかかわらず、すべてのユーザーがインターフェースを理解できるようになります。

フィードバックのベストプラクティス
現実的な動き

ユーザーの期待やジェスチャーに沿ったアニメーションを設計します。フィードバックは次のようにします。

  • 「短く、的確」
  • 軽量
  • 気を散らせることなく、情報を効果的に伝える
頻度に関する考慮事項

**頻繁に行われる UI 操作にはアニメーションを使用しないでください。**標準のシステム要素にはすでに控えめなアニメーションが含まれているため、カスタム要素で一般的な操作に不要な動きを加えるべきではありません。

ユーザーによる制御

特に操作を繰り返す場合、次に進む前にアニメーションの完了を待つよう強制せず、「ユーザーが動きをキャンセルできるようにします」。

// ✅ Allow immediate tap, don't block on animation
Button("Next") {
    withAnimation(.easeOut(duration: 0.2)) {
        showNext = true
    }
}
// User can tap again immediately, not forced to wait
プラットフォーム固有のガイダンス
visionOS
  • 周辺視野の端では動きを避けます。不快感の原因になります
  • オブジェクトを移動する際は、目に見える動きではなくフェードを使用します
  • 静止した基準点を保ちます
  • 持続的な振動を避けます(特に周波数が 0.2 Hz の場合)
  • 仮想世界の回転を防ぎます(安定性が損なわれます)
watchOS

SwiftUI はアニメーション機能を提供し、WatchKit はレイアウトアニメーションやシーケンスに WKInterfaceImage を提供します。


アイコンとシンボル

SF Symbols

San Francisco フォントに一致し、Dynamic Type に合わせて拡大縮小し、太字テキストやダークモードにも自動的に適応する 6,900 以上のベクターシンボルです。9 種類のウェイト、3 種類のスケール、4 種類のレンダリングモード、12 種類以上のアニメーション効果があります。

詳しい情報は、レンダリングモード(モノクロ、階層、パレット、マルチカラー)、シンボルエフェクト(バウンス、パルス、揺れ、描画の開始/終了)、カスタムシンボルの作成について、axiom-sf-symbols(判断ツリー)と axiom-sf-symbols-ref(API 全体)を参照してください。

カスタムインターフェースアイコン

**デザイン原則:**見慣れた視覚的な比喩を用いた、認識しやすく簡潔なデザインにします。サイズ、詳細度、線の太さ、遠近感を統一します。アイコンのウェイトを隣接するテキストに合わせます。視覚的な重みが非対称な場合は、視覚的に中央に配置されるようパディングを調整します。

**形式:**自動スケーリングには PDF または SVG を使用します。システムコンポーネントは選択状態を自動的に処理します。

アイコンとテキストの使い分け

WWDC25 より:「鉛筆は注釈を、チェックマークは確定を示すように見えるかもしれません。そのため、「選択」や「編集」といった操作を誤解しやすくなります。明確な略記方法がない場合は、常にテキストラベルを選ぶのが適切です。」

アイコンを使う場合:

  • シンボルに明確で普遍的な意味がある(共有、削除、設定)
  • スペースに制約がある
  • アイコンによって素早く見分けやすくなる

テキストを使う場合:

  • 操作に明確なシンボルがない
  • 似た操作が複数ある
  • スペースより明確さが重要である
アクセシビリティ

VoiceOver で説明できるよう、必ず代替テキストラベルを指定してください。

Image(systemName: "star.fill")
    .accessibilityLabel("Favorite")

ジェスチャーと入力

ジェスチャー設計の基本原則

一貫性と親しみやすさ:「ユーザーは、現在の状況にかかわらず、ほとんどのジェスチャーが同じように機能することを期待します。」タップ、スワイプ、ドラッグなどの標準的なジェスチャーは、すべてのプラットフォームで期待される機能を実行する必要があります。

応答性の高いフィードバック:「ジェスチャーには可能な限り応答性高く対応し」、ジェスチャーの実行中にすぐフィードバックを提供して、ユーザーが結果を予測できるようにします。

標準的なジェスチャー

すべてのプラットフォームでサポートされる基本的なジェスチャー(ただし、正確な動きはデバイスによって異なります)。

  • タップ
  • スワイプ
  • ドラッグ
  • ピンチ
  • 回転(iOS/iPadOS)
  • 長押し
タッチターゲットの要件

タッチターゲットの最小サイズ:

プラットフォーム最小サイズ間隔
iOS/iPadOS44x44 ポイント12-24pt のパディング
macOSコントロールによって異なるシステムの間隔
watchOSシステムコントロール小さな画面に最適化
tvOS大きめ(フォーカスモデル)60pt 以上の間隔
// ✅ Adequate touch target
Button("Tap") { }
    .frame(minWidth: 44, minHeight: 44)

// ❌ Too small
Button("Tap") { }
    .frame(width: 20, height: 20) // Fails accessibility
カスタムジェスチャーのガイドライン

カスタムジェスチャーは必要な場合にのみ実装し、次の条件を満たす必要があります。

  • 見つけやすい — ユーザーが見つけられること
  • 簡単に実行できる — 操作しやすいこと
  • 他のジェスチャーと区別できる — 競合しないこと
  • 唯一の方法にしない — 重要な操作には代替手段を用意すること

警告: 標準のジェスチャーをカスタムジェスチャーに置き換えないでください。ショートカットは、使い慣れた操作を置き換えるのではなく、補完するものです。

アクセシビリティ

重要: 「アプリを操作する方法を複数用意してください。」ユーザーが特定のジェスチャーを実行できると決めつけないでください。

代替手段を用意する:

  • 音声コントロール
  • キーボード操作
  • ジェスチャーの代わりとなるボタン
// ✅ Swipe action + button alternative
.swipeActions {
    Button("Delete", role: .destructive) {
        delete()
    }
}
.contextMenu {
    Button("Delete", role: .destructive) {
        delete()
    }
}

起動とオンボーディング

起動画面

必須: iOS、iPadOS、tvOS
不要: macOS、axiom-visionOS、watchOS

デザイン原則: 唐突な視覚的変化を避けるため、「アプリまたはゲームの最初の画面とほぼ同じ起動画面をデザインする」こと。

ベストプラクティス

ブランディングを最小限にする:

  • ロゴは避ける
  • スプラッシュ画面は使用しない
  • 装飾的な演出は加えない
  • 目的:ブランドをアピールするのではなく、素早く起動する印象を高める

テキストを使用しない:

  • 起動画面のコンテンツはローカライズできない
  • テキストは一切使用しない

外観を一致させる:

  • デバイスの向きを尊重する
  • ライトモード/ダークモードに対応する
// Launch screen matches first screen
// Transitions smoothly without flash
オンボーディング

オンボーディングは、起動フェーズの後に続く独立したエクスペリエンスです。「アプリまたはゲームの概要」を示し、必要に応じてスプラッシュ画面を含めることができます。

使用するタイミング: 新規ユーザーに伝える価値のある情報がある場合に限ります。

オンボーディングに含められる内容:

  • ブランディングとスプラッシュ画面
  • 学習コンテンツ
  • 権限のリクエスト
  • アカウントの設定

流れ:

  1. 起動 — システムが起動画面を表示し、最初の画面に遷移する
  2. オンボーディング(任意) — ブランディングや学習コンテンツを含めることができる
  3. 継続利用 — 「アプリを再起動したときに前回の状態を復元し、ユーザーが中断したところから続けられるようにする」

プラットフォーム固有のガイダンス

iOS

タブバーのガイドライン:

  • iPhone ではタブは最大 5 つ(6 つ目以降は自動的に「その他」に入る)
  • すべてのタブにアイコンとテキストラベルの両方が必要 — アイコンのみでは HIG に違反する
  • 常に表示する — タブ内の画面遷移中に非表示にしない
  • タブの順序は利用頻度を反映する(最もよく使うタブを左側に配置)
  • タブの状態を維持する:切り替え時にスクロール位置とナビゲーションの状態を保持する
  • iOS 26:Liquid Glass は自動で適用される — カスタムのぼかしやマテリアルの背景を追加しない
  • iPad:横向きではタブバーからサイドバーに切り替える。適応には TabView と Tab を使用する

ナビゲーションバーのガイドライン:

  • 常にシステムの戻るボタン(シェブロン)を使用する — カスタムの「X」に置き換えない
  • タイトルにはアプリ名ではなく、現在のビューの内容を示す
  • 大きなタイトル(prefersLargeTitles)は最上位のビューのみで使用し、遷移先のビューではインライン表示にする
  • ツールバーアクションは最大 1~3 個にし、追加分には ... メニューを使用する
  • iOS 26:ビュー間の遷移に合わせてツールバーが変化する Liquid Glass

システムとの統合: ウィジェット、ホーム画面のクイックアクション、Spotlight、ショートカット、アクティビティビュー

iPadOS

大きなディスプレイ、サイドバーナビゲーション、分割表示、ポインター/トラックパッド、任意のウィンドウ(iOS 26 以降)により、iOS を拡張します。iOS のレイアウトを単に拡大するのではなく、サイドバーや分割表示を活用してください。

macOS

ポインター操作を優先し、キーボードを中心に設計します。iOS より情報密度を高くし、コントロールを小さくします。複数のウィンドウ、メニューバー、コンテキストメニュー、キーボードショートカットが不可欠です。コントロール:ミニ/小/中 → 角丸長方形、大/特大 → カプセル形。

watchOS

非常に小さなディスプレイで、ひと目で確認でき、操作は最小限です。画面全体に広がるコンテンツ、最小限の余白、Digital Crown による操作、文字盤用のコンプリケーションを使用します。常時表示ディスプレイへの配慮も必要です。

iPad/iOS からの適応: サイドバーをページベースのフローに置き換えます。スワイプ/ピンチ操作を Digital Crown の回転に変換します。階層の表現には、不透明度や間隔を使います(マテリアル/Liquid Glass は使用しません)。ダッシュボードはコンプリケーションに置き換えます。@State/@Environment は再利用しやすい一方、ビュー階層は書き直す必要があります。

tvOS

10 フィート離れた視聴距離、フォーカスベースのナビゲーション、ジェスチャー操作のリモコンに対応します。タッチターゲットを大きくし、フォーカス状態を目立たせ、テキスト入力を最小限に抑え、方向キーによるナビゲーションに対応します。

フォーカスエンジン: tvOS はハードウェアナビゲーションに UIKit Focus Engine を使用し、SwiftUI の @FocusState と共存します。最終的な決定権はフォーカスエンジンにあります。フォーカスエンジンがビューをフォーカス不可と判断した場合、@FocusState の割り当ては無視されます。分離したビュー間のナビゲーションの隙間を埋めるには、UIFocusGuide を使用します。

TVUIKit: tvOS 専用のコンポーネントです。TVPosterView(視差フォーカス効果)や TVDigitEntryViewController(PIN 入力)があります。SwiftUI に同等のものはなく、UIViewRepresentable を介して接続します。

テキスト入力: 標準のテキストフィールドを使用すると、システムのフルスクリーンキーボードが表示されます。より優れた UX のためには、シャドウ入力パターン(Button UI +非表示の CocoaTextField)を使用します。実装の詳細は axiom-tvos を参照してください。

ストレージ: ローカルに永続化できるストレージはありません。ローカルファイルはすべてキャッシュであり、システムによって削除されます。データ戦略については axiom-tvos を参照してください。

visionOS

ガラス素材、3D レイアウト、奥行きを備えた空間コンピューティングです。快適な視距離を保ち、頭部に固定されるコンテンツを避け、視野の中央にコンテンツを配置します。


インクルーシブデザイン

言葉遣いとコミュニケーション

誰もが受け入れられる言葉遣いの要件:

  • 平易で、直接的かつ敬意のある口調を使います
  • 学歴を理由に排他的であるかのような印象を与えないようにします
  • 「ユーザー」ではなく、「あなた/あなたの」として相手に直接語りかけます
  • 専門用語や技術用語が必要な場合は、その意味を説明します
  • 文化に特有の表現を、平易な代替表現に置き換えます

抑圧的な起源を持つ表現(例:「peanut gallery」)は避けます。

ユーモアの使用には注意します。 ユーモアは主観的で、文化を越えて翻訳することが難しいためです。

視覚表現

多様な人々の描写:

  • 人種的背景、体型、年齢、身体能力に幅のある人々を取り上げます
  • 職業や行動におけるステレオタイプな描写を避けます

決めつけを避ける:

  • 家族構成を狭く定義しないようにします
  • 誰もが同じ経験をすると思い込まないようにします
  • 文化に特有のセキュリティ質問を、より幅広い人に当てはまる経験に置き換えます
ジェンダーアイデンティティと代名詞

ベストプラクティス:

  • コピーで不必要に性別に言及しないようにします
  • 「ノンバイナリー」「自分で指定する」「回答しない」などの選択肢を用意します
  • 性別を特定しない画像を使います
  • アバターやキャラクターをカスタマイズできるようにします
アクセシビリティと障害

理解すること:

  • 障害にはさまざまな程度があります
  • 一時的な障害や状況による障害は、誰にでも起こり得ます

取り入れること:

  • 多様性を表す際に、障害のある人々を含めます
  • 文章では人を第一に考えるアプローチを採用します(「障害のある人」は「障害者」よりも適切です)
ローカライズとグローバルな考慮事項

ソフトウェアを以下に備えます:

  • 国際化
  • 複数言語への翻訳

色の文化的な意味への配慮:

  • 色が持つ意味は文化によって異なります
  • 白は、ある文化では死を、別の文化では純潔を表します
  • 赤は、ある文化では危険を、別の文化では肯定的な意味を表します

平易な言葉を使い、ステレオタイプを避けることで、ローカライズを円滑に進めます。


ブランディング

基本原則

ボイスとトーン: 文章によるコミュニケーションを通して、一貫したブランドの個性を保ちます。

視覚要素:

  • UI コンポーネントにアクセントカラーを使用することを検討します
  • ブランドとの強い結びつきがある場合はカスタムフォントを検討します(ただし、本文には可読性に優れたシステムフォントが適しています)
重要な制約事項のガイドライン

最も重要な指針 — 控えめにする:

コンテンツを優先する:「ブランド素材を表示するだけで、ほかに何もしない要素に画面スペースを使うと、ユーザーが重視するコンテンツを表示するスペースが少なくなる可能性があります。」

ロゴは最小限に:「コンテキストを伝えるうえで不可欠な場合を除き、アプリやゲーム全体にロゴを表示したいという誘惑に抗いましょう。」

**おなじみのパターン:**デザインにスタイルを加える場合も、標準的な UI の動作やコンポーネントの配置を維持して、使いやすいインターフェースにしましょう。

**起動画面に関する注意:**起動画面はすぐに消えるため、ブランディングに使用するのは避けましょう。ブランドを取り入れるには、代わりにオンボーディング画面を検討してください。

適切なブランディング

推奨事項:

  • ブランドのアクセントカラーをアプリのティントカラーとして使用する
  • オンボーディングにブランディングを取り入れる(起動画面ではなく)
  • コピーにブランドの語り口を反映する
  • クロームではなくコンテンツ内でブランドを取り上げる

避けること:

  • ナビゲーションバーにロゴを表示する
  • システムの背景をブランドカラーで上書きする
  • スプラッシュ画面を追加する
  • ブランディングをコンテンツと競合させる
法的な考慮事項

Apple の商標をアプリ名や画像に使用することはできません。Apple の公式商標ガイドラインを確認してください。


HIG に関するよくある問題のトラブルシューティング

色のコントラスト不足

**症状:**アクセシビリティ違反で App Store の審査に却下される、または色が WCAG の基準を満たさない。

**診断:**Accessibility Inspector、コントラスト計算ツール、ライトモードとダークモードの両方、コントラストを上げる設定を有効にした状態でテストします。コントラスト比の要件については、上記の「アクセシビリティ」>「視覚」セクションを参照してください。

解決策:

// ❌ Custom gray may fail contrast
Text("Label").foregroundStyle(.gray)

// ✅ Semantic colors (automatic compliance)
Text("Label").foregroundStyle(.secondary)

// ✅ Verified custom color (~8:1 on white, WCAG AAA)
Text("Label").foregroundStyle(Color(red: 0.25, green: 0.25, blue: 0.25))
タッチターゲットが小さすぎる

**症状:**タップしにくいというユーザーからの報告、またはアクセシビリティ上の理由による App Store の審査却下。

診断:

// Check button size
Button("Tap") { }
    .frame(width: 30, height: 30) // ❌ Too small

解決策:

// ✅ Expand touch target to minimum 44x44
Button("Tap") { }
    .frame(minWidth: 44, minHeight: 44)

// ✅ Alternative: Add padding
Button("Tap") { }
    .padding() // System adds appropriate padding
ダークモードの問題

**症状:**ダークモードで色が正しく表示されない、コントラストが不十分。

診断:

  • 適応しないハードコードされた色
  • ダークモード用のバリエーションがないカスタムカラー
  • 両方の外観モードでテストしていない

解決策:

// ❌ PROBLEM: Hardcoded white text
Text("Label").foregroundStyle(.white)
// Invisible in Light Mode

// ✅ SOLUTION: Semantic color
Text("Label").foregroundStyle(.primary)
// Black in Light, white in Dark

// ✅ ALTERNATIVE: Asset catalog color with variants
Text("Label").foregroundStyle(Color("BrandText"))
// Define in Assets.xcassets with Light/Dark variants
細いフォントの読みやすさ

**症状:**特に小さいサイズや明るい場所で、テキストが読みにくい。

診断:

Text("Headline")
    .font(.system(size: 17, weight: .ultralight)) // ❌ Too light

解決策:

// ✅ Use Regular minimum
Text("Headline")
    .font(.system(size: 17, weight: .regular))

// ✅ Better: Use system text styles
Text("Headline")
    .font(.headline) // Automatically uses appropriate weight
Dynamic Type が機能しない

症状:「設定」でユーザーがテキストサイズを変更しても、テキストが拡大・縮小しない。

// ❌ Fixed size doesn't scale
Text("Label").font(.system(size: 17))

// ✅ Text styles scale automatically
Text("Label").font(.body)

// ✅ Custom font with scaling
Text("Label").font(.custom("CustomFont", size: 17, relativeTo: .body))
視差効果を減らす設定が反映されない

**症状:**動きに敏感なユーザーに不快感が生じる。

診断:

  • 設定に関係なくアニメーションが常に再生される
  • 動きに敏感なユーザー向けの代替手段がない

解決策:

// ✅ Check Reduce Motion setting
@Environment(\.accessibilityReduceMotion) var reduceMotion

var body: some View {
    content
        .animation(reduceMotion ? nil : .spring(), value: isExpanded)
}

// ✅ Alternative: Simpler animation
.animation(reduceMotion ? .linear(duration: 0.1) : .spring(), value: isExpanded)
VoiceOver のラベルがない

**症状:**VoiceOver が操作内容ではなく「ボタン」のような役に立たない情報を読み上げる。

診断:

// ❌ Image button without label
Button {
    share()
} label: {
    Image(systemName: "square.and.arrow.up")
}
// VoiceOver says: "Button"

解決策:

// ✅ Add accessibility label
Button {
    share()
} label: {
    Image(systemName: "square.and.arrow.up")
}
.accessibilityLabel("Share")
// VoiceOver says: "Share, Button"
色だけで情報を伝えている

**症状:**色覚異常のユーザーがステータスを区別できない。

診断:

// ❌ Only color indicates state
Circle()
    .fill(isComplete ? .green : .red)

解決策:

// ✅ Use shape + color + text
HStack {
    Image(systemName: isComplete ? "checkmark.circle.fill" : "xmark.circle.fill")
    Text(isComplete ? "Complete" : "Incomplete")
}
.foregroundStyle(isComplete ? .green : .red)
起動画面のブランディングによる審査却下

**症状:**ロゴやテキストが含まれている起動画面を理由に、App Store の審査で却下される。

診断:

  • 起動画面にブランディング要素が含まれている
  • 起動画面にローカライズできないテキストがある

解決策:

// ❌ Launch screen with logo (rejected)
// Launch.storyboard contains app logo

// ✅ Launch screen matches first screen (approved)
// Launch.storyboard shows same background/layout as first screen
// No text, no logos, minimal branding

// Move branding to onboarding screen instead
外観のカスタム切り替えに関する問題

**症状:**アプリ固有のダークモード設定や、設定項目の重複にユーザーが戸惑う。

診断:

  • アプリに独自のライト/ダーク切り替えがある
  • システムの「設定」→「画面表示と明るさ」と競合する

解決策:

// ❌ App-specific appearance toggle
.preferredColorScheme(userPreference == .dark ? .dark : .light)

// ✅ Respect system preference
// Remove custom toggle, use system preference
// Let iOS Settings control appearance

リソース

WWDC:356、2019-808

ドキュメント:/design/human-interface-guidelines, /design/human-interface-guidelines/color, /design/human-interface-guidelines/dark-mode, /design/human-interface-guidelines/materials, /design/human-interface-guidelines/typography, /design/human-interface-guidelines/layout, /design/human-interface-guidelines/accessibility, /design/human-interface-guidelines/icons

スキル:axiom-hig, axiom-liquid-glass, axiom-liquid-glass-ref, axiom-swiftui-layout-ref, axiom-accessibility-diag, axiom-tvos


最終更新:Apple HIG(2024-2025)、WWDC25-356、WWDC19-808 に基づく スキルの種類:リファレンス(コード例を含む包括的なガイド)

コメント