macOS設定ウインドウのガイドライン
はじめに
macOSのアプリが備える「設定」のUIには、現在のHIGでは言語化されていない多くのデザインのお作法・慣習があり、macOSプラットフォームにおいて高品質と感じられるアプリを目指すためには、デベロッパーがこれらの事柄を積極的に意識し、アプリのデザインに取り入れる必要があります。本記事では、macOSで一般的とされるデザインの要点について、現在と過去のHIG、関連する資料、筆者による解釈等を引用しながら、それらを改めて日本語でまとめ、その認知を広げることを目指します。
本記事では具体的なコードはほとんど紹介しませんが、AppKitを使用することを前提に、その関連するAPI等のデベロッパー資料に言及します。SwiftUIについては筆者が十分な検証を行えていないため対象外としますが、UIの基本的な考え方は同じであるはずなので、デザインの参考になるはずです。
この記事の内容は、2025年6月現在、macOS 15.5 Sequoiaを前提にしています。プラットフォーマーから新しいデザイン言語が示された場合には、まずはそちらを参照するようにしてください。
設定ウインドウ
基本のUI部品
- ウインドウ(NSWindow)
- ウインドウコントローラー(NSWindowController)
- ツールバー(NSToolbar) ※タブを設ける場合
- タブビュー(NSTabView) ※タブを設ける場合
- タブビューコントローラー(NSTabViewController) ※タブを設ける場合
NSWindowControllerを使うかどうか、NSTabViewを使うかどうかは実装者の気持ちや設計次第ですが、NSToolbarは設定UI専用のスタイルと挙動を備えているため、タブを扱うならこれの使用は必須となります。
インタラクション設計
設定ウインドウの一般的なインタラクション設計とその要点を解説します。
アプリケーション
呼び出し動線とメニュー項目
設定ウインドウは、必ずアプリケーションメニュー内のコマンドから表示できるようにします。メニュー項目名は「Settings…」(US英語)または「設定…」(日本語)とします。他の言語でも設定に関する表記のルールがあるため、それぞれの言語環境での表記を参考にしてください。
Finderのアプリケーションメニュー
macOS 12 Monterey以前のmacOS環境では、それぞれ「環境設定…」「Preferences…」表記が使われていたため、古いOSをターゲットとする場合には要注意です。
macOSの「設定」に関わる正しい表記
US英語 | 日本語 | |
---|---|---|
macOS 13 Ventura以降 | Settings(…) | 設定(…) |
macOS 12 Monterey以前 | Preferences(…) | 環境設定(…) |
なお、macOS 13 Ventura以降においては、当該メニュー項目のタイトル「Preferences…」US英語表記は、システムがランタイムで自動的に「Settings…」に書き換えるため、デベロッパーは基本的にローカライズの文言とメニュー以外の表記に対応すれば十分です。この辺りの具体的な挙動は次の記事で言及しているので、気になるようであれば参考にしてください。
キーボードショートカット
キーボードショートカットには必ず⌘
+,
を当てます。Storyboardベースでプロジェクトを作っていれば、テンプレートに自動で組み込まれているため、ほとんど設計ミスを気にすることはないでしょう。
設定変更の即時反映と保存(モードレス化)
ユーザーが設定を変更したら、その内容は即時にアプリに反映します。データバインディング、通知、その他適当な技術を用いて、設定のUIと各種状態の同期をとるようにしてください。UIはモーダル化せず、モードレスです。要するに、設定ウインドウには「保存」「キャンセル」のようなボタンは備わりません。
設定値はUserDefaultsに永続化し、アプリ起動時や設定UIの表示の際にはそれらを適切に反映するようにしてください。
ウインドウ
モードレスウインドウ
設定ウインドウはモードレスにします。すなわち、モーダルダイアログやアプリケーションモーダルで表示しないでください。また、「キャンセル」「保存」「完了」「適用」のような、モーダル的な決定および破棄ボタンを用意しないでください。「設定変更の即時反映と保存(モードレス化)」でも説明したように、設定ウインドウでの変更は即時にアプリに反映し、そこにモードを生じさせないようにしましょう。
Apple製のアプリの中で「Music」アプリはモーダルな設定ウインドウを提供していますが、これは誤った設計なので真似しないでください。
Music.appの設定ウインドウ。これは間違ったUI設計になってしまっているため、真似をしないこと。
閉じるボタンのみを有効化
HIGでは「設定ウインドウの最小化/最大化ボタンを暗くする。」とあり、ウインドウのコントロールボタンのうち、閉じるボタン(赤いバツボタン)のみを有効にします。Dockにしまうための最小化ボタン(黄)や、フルスクリーン/ズームのための最大化ボタン(緑)は、無効にします。
Escapeや⌘+.でも閉じられるようにする
設定ウインドウはEscapeや⌘
+.
によって閉じられるようにしましょう。この実装を行っていないApple製のアプリもいくつか見られますが、基本的には対応すべきです。
NSWindowやNSWindowControllerでは、上記のキャンセル操作が実行されると、NSResponderの暗黙的な設計により、cancel:
メソッドでこのメッセージを受け取ることができます。引数名はAny型のsender
です。
参考:
cancelOperation: - NSResponder Class Reference (WebArchive 20140603045053)
How to close window (NSWindowController) by hitting the ESC key?
限定的に最大化ボタンも有効化(筆者による解釈)
HIGでは「設定ウインドウの最小化/最大化ボタンを暗くする。」とあり、緑の最大化ボタンは有効にすべきでないとされています。しかし、Xcodeの設定ウインドウが一部でこのルールを無視していることや、Xcodeのようなユースケースでは実際に最大化ボタンを使えた方がユーザビリティが良くなると考えられるため、筆者としては、次の条件に当てはまる場面においては、最大化ボタンならびにウインドウのリサイズを許容しても良いと考えています。
- アクティブなペインの内容量が多い場合
- アクティブなペインの内容に、スクロール可能なリストUIを埋め込んでいる場合
NSWindowのStyleMask
のうち、.miniaturizable
.resizable
属性をそれぞれ入れ替えることで、動的に最小化/最大化(リサイズ)の有効無効を制御することができます。
最大化やリサイズを有効にする場合は、NSWindowの最小サイズと最大サイズの設定も忘れずに。
Xcodeの設定ウインドウのうち、スクロールビューを内包するペインの様子
留意点
- 最大化ボタンは標準の「フルスクリーン」ではなく、伝統的なプラス記号の「拡大/縮小」にする
NSWindowのcollectionBehavior
に.fullScreenAuxiliary
を入れると、プラス記号の「拡大/縮小」になります。 - 上記の条件に当てはまらないペインがアクティブの際には、最大化ボタンを無効化する
タブで設定項目をグループ化する
設定項目の種類が多く見込まれる場合には、ツールバー(NSToolbar)を使ってグループを形作りましょう。グループを作る必要がないと判断できるなら、単一ペインのまま、ツールバー/タブを備えない設定ウインドウも使えます。
ツールバー/タブがない場合には、HIGに従い、ウインドウのタイトルを「APP_NAMEの設定」としましょう(テキストエディットの例はHIGの言及とは異なっています)。
Font Bookの設定ウインドウ
テキストエディットの設定ウインドウ
専用タブスタイル
ツールバー(NSToolbar)には設定ウインドウ用の専用スタイルが備わっており、必ずこれを使いましょう。見た目を真似たまったく異なる実装でタブの再現を試みたり、タブではない表現(例えば、サイドバーナビゲーションなど)を採用しないでください。iOSアプリや他のプラットフォームとのUIデザインの共通化も避けてください。
ツールバーを設定のスタイルにするには、NSToolbarではなく、NSWindowのAPIを使います。toolbarStyle
プロパティに.prefenrece
属性を当ててください。
NSToolbarの設定専用スタイル
ツールバー(タブ)のカスタマイズを無効にする
ツールバー(NSToolbar)にはカスタマイズのための機能が備わっていますが、設定ウインドウではユーザーにカスタマイズ機能を提供しないでください。
タブには必ずアイコンとラベルを付ける
タブには必ずアイコンとラベルを付けましょう。
設定ウインドウの幅が小さくなると、ツールバーの中身が省略表示になることがあります。この時に、隠されたタブはテキストとメニューの形でまとめられるので、ラベルの設定を忘れるとアクセシビリティ上の問題が生じます。
アイコンのビジュアルスタイルはSF Symbolsまたはそれ風のものを独自で用意しましょう(macOS 15 Sequoia時点)。ただし、macOSのバージョンによっては適切なスタイルが変わることがあるので、その時のOSのスタイルをよく観察し、適切な表現をデザインしてください。
1Passwordの設定ウインドウ、ツールバーが省略表示になった様子。
慣例的なタブ
ルール化されていないものの、タブには慣例的に次のようなものが並ぶ傾向にあります。
- 「一般」
- 歯車(SF Symbolsでは
custom.gearshape
) - アプリの一般的な設定項目を収める
- 1番目に配置
- 歯車(SF Symbolsでは
- 「詳細」
- 二重の歯車(SF Symbolsでは
gearshape.2
) - アプリの高度な設定を収める
- 最後またはその付近に配置
- 二重の歯車(SF Symbolsでは
Font Bookの設定ウインドウ
そのほか、よく見られるタブには次のようなものがあります。
- 「表示」または「外観」
- メガネ(SF Symbolsでは
eyeglasses
) - 表示やアピアランスに関する設定を収める
- メガネ(SF Symbolsでは
- 「テーマ」
- 筆(SF Symbolsでは
paintbrush
) - アピアランス変更に関する設定を収める
- 筆(SF Symbolsでは
- 「通知」
- 鐘(SF Symbolsでは
bell
)
- 鐘(SF Symbolsでは
- 「検索」
- 虫眼鏡(SF Symbolsでは
magnifyingglass
)
- 虫眼鏡(SF Symbolsでは
- 「機能拡張」
- パズルピース(SF Symbolsでは
puzzlepiece.extension
)
- パズルピース(SF Symbolsでは
- 「プライバシー」
- 手のひら(SF Symbolsでは
hand.raised
)
- 手のひら(SF Symbolsでは
- 「フォントとカラー」
- Aa/あぁ(SF Symbolsでは
textformat
のローカライズ対応) - フォントに関する設定を収める
- Aa/あぁ(SF Symbolsでは
- 「デベロッパ」
- レンチとドライバー(SF Symbolsでは
wrench.and.screwdriver
) - 開発者向けのより高度な設定を収める
- レンチとドライバー(SF Symbolsでは
Safariの設定ウインドウ
スクリーンの中央に表示する/前回の表示位置を復元する
設定ウインドウは、初回表示の際には主スクリーンの中央に表示します。これにはNSWindowのcenter()
メソッドを使いましょう。このメソッドを使うと、ウインドウは厳密にはY方向に少し上がったような位置に表示されますが、これは想定された挙動であり、仕様です。
アプリが生きている間には、前回表示したウインドウの座標を保持し、次の再表示の際にはそれを復元するようにしてください。NSWindowControllerを使っていれば、NSWindowを解放しない限りはこれをほぼ自動的に実現することができます。
アプリ終了後のウインドウ座標の復元/永続化まで考慮する必要はないと考えますが、これを実現したければ、windowFrameAutosaveName
を使うことができます。
アニメーションによるリサイズ
タブ間(ペイン)の切り替えの際には、ペインのサイズ(またはその内容)に合わせて、ウインドウを適切な大きさにリサイズしてください。その際にはイージングの効いたアニメーションを適用しましょう。
アクセシビリティの「視差効果を減らす」が有効の場合には、アニメーションを無効化するとより親切でしょう。
参考
タブ切り替え時の表示方法
タブ間(ペイン)の切り替えの際には、アニメーションがある場合には、それが描画しきるまで内容を表示しないでください。タブ切り替えが始まった時にまず既存のペインを非表示にし、ツールバー以外をまっさらにした上でリサイズをかけ、リサイズが完了したら新しいペインを表示します。
古いMac OS Xにおいては、ペインの内容を都度読み込み中であることを示すインジケータが表示されていたことがあり、その名残りであると考えられます。これは、AppleScriptのスクリプトエディタの設定ウインドウで今でも見られます。
タイトルバーに現在のタブ名を表示する
HIGでは「現在表示されているパネルに合わせてウインドウのタイトルをアップデートする。」とあり、設定ウインドウのタイトルには現在アクティブなタブ(ペイン)の名前を反映するようにしてください。
タイトルの付け方や反映のタイミングはApple製アプリでも割と一貫性がないのですが、Safariのように、リサイズのアニメーションの描画が終わって完全に切り替わった時にタイトルも更新すると良いでしょう。
タブがない場合には、タイトルを「APP_NAMEの設定」としましょう。
再表示の際に、アクティブなタブの状態を復元する
HIGでは「最後に表示したパネルを復元する。」とあり、最後に表示したタブ(ペイン)を選択状態にして復元しましょう。タブの状態が毎度リセットされてしまうと、ユーザーが設定を何度も操作しようとする際に不便に感じられるためです。
設定への直ジャンプ
アプリによっては、メニューバー以外の部分から直接設定にジャンプできる動線を設置することがあります。例えば、何かのアカウントを扱うUIから、それに関連する設定を表示するような場面などが考えられます。そのような場合には、設定ウインドウの表示の際に最後のタブを復元するのではなく、対応する適切なタブを自動でアクティブにしてあげるとよいでしょう。
ヘルプへの動線/「?」ボタン
必要であれば、各ペインの右下(RTLでは左下)には関連するヘルプへの動線として「?」ボタンを設置しましょう。独自のアイコンやボタンを設計するのではなく、AppKitが用意する標準のNSButtonとヘルプスタイルを採用してください。
ヘルプボタンの先には、可能であればOS標準のヘルプビューアで用意したローカルのヘルプ文書を開くようにしましょう。これが難しいようなら、関連するWebリソースや他の方法でヘルプ文書を開いてあげられると、設定のユーザビリティが向上します。
Safariのヘルプボタン
ウインドウの背景はデフォルトの色にする
背景には独自の色を着色したりはせず、ウインドウの地の色が透けて見えるようにします。システムのセマンティックな背景色を直に適用することで、ダークモードへの対応や、OSバージョンごとのスタイルの違いをそのまま受け入れられるようになります。
設定項目
肯定的な表現に寄せる
設定項目は、なるべく肯定的な表現「〜を表示」「〜にする」に寄せましょう。否定的な「〜を表示しない」「〜を非表示」「〜しない」を採用すると、意味の理解が難しくなるため、なるべく全体を肯定的な表現にしてから、それらを有効化するという一貫性を持たせるようにします。
もしも「〜しない」を採用したくなった場合には、それを「〜にする」にした上で、その設定のデフォルト値を有効にしておく形で対処してみてください。
設定系UIはなるべく1つにまとめる
設定関係のUIがあちこちに点在していると、ユーザーは混乱してしまいます。似たようなUIを複数用意するのではなく、「設定項目は『設定ウインドウ』一箇所にまとまっている」状況を目指すようにしましょう。また、それらを「設定」「オプション」「コンフィグ」といった具合に、類似表現を複数混在させたり区別したりするようなこともなるべく避け、概念を「設定」で統一しましょう。
一方、ライセンスのアクティベーション用UIなど、それを設定ウインドウから切り離す意義と理由がはっきりと認められる場合には、例外的にそれらを設定ウインドウから分離することも検討できます。
UIの表示切り替え系はなるべく表示メニューで対処する
サイドバーの表示/非表示など、何かのUIのトグル表示は設定ウインドウで扱うのではなく、メニューバーの表示メニューに収めることを検討してください。そのステートはアプリ全体のグローバル領域で管理し、最後に扱った表示のステートを次のウインドウの新規作成時に採用するような形にすると、自然に感じられます。
Safariの表示メニュー
一方、UIの詳細なレイアウトを切り替えたりするような機能を想定するのであれば、表示メニューよりも設定ウインドウで扱った方が無難かもしれません。
Pixelmator Proのワークスペース設定
レイアウト
レイアウトに言語化された厳密なルールはありませんが、意識すると良い観点をいくつか紹介します。
レイアウトルール
基本的には センターイコライゼーション (Center equalization) と呼ばれる、視覚的に中央に寄って調和が取れたように見えるレイアウト方法を採用します。ウインドウ全体を横に二等分する仮想のガイド線を想定した時に、単に横方向の値を2で割った位置にするのではなく、左右の要素が視覚的に調和が取れて見えるように調整します。情報量だけで見ると実際には右側に偏っていますが、長めの見出しラベルの存在によって、視覚的な全体の調和は保たれます。
Center equalization – Apple Human Interface Guidelines (2004-08), Apple Computer, Inc.
Storyboard / Xibのガイドに従う
Interface Builderを使用すると、macOSで推奨されるマージンをガイド線で示してくれるので、レイアウトに便利です。例えばウインドウの隅から内側に対しては20ptのマージン、コントロール同士では横に8pt、縦に6ptのマージンが示されたりします。
ただし、Interface Builderが示すガイドだけでは設定ウインドウとしての良いレイアウトを実現できないため、視覚的な調整や暗黙のルールを取り入れる必要があります。
各マージンに推奨される具体的な値は、Mario Guzman氏が過去のHIGを参考に取りまとめたこちらの資料を参考にしてください。
見出し
見出しとなるラベルをペインの左側(RTLでは右側)に置き、右揃え(RTLでは左揃え)で配置します。右揃えの起点は機械的な絶対値にするのではなく、そのペイン全体の視覚的なバランスで相対的に位置を決めましょう。
テキストは機能名や設定区分がわかるような短めのタイトルケースにし、句読点を含めず、末尾には半角のコロン(:)を付けます。
見出しのフォントはシステムフォントのRegularとし、サイズは標準の13pt(Regularサイズ相当)にします。ウェイトをBoldにする例もありますが、筆者の見解ではRegularの方が良いと考えます。ここはApple製アプリでも解釈が分かれているため、一貫したルールが存在するわけではないようです。
整列例(各ピクセル値は当時のもので、現在は一部異なる) – Apple Human Interface Guidelines (2004-08), Apple Computer, Inc.
詳細要素
見出しと対応するコントロール等を見出しのベースラインに合わせてその右隣(RTLでは左)に並べて配置します。ちょうど全体が2カラムになるような形でテーブルレイアウトを意識しましょう。両者(カラム同士)のマージンには8ptを確保します。
見出しがローカライズされる可能性を考慮し、比較的長い単語が入ってきても表示し切れるよう、十分に余白を確保しながらレイアウトしましょう。単一のレイアウトではどうしても対応が難しい場合には、動的なレイアウトの仕組みを取り入れるか、最悪2行表示できる余地なども考えてみてください(1行で表示し切ることが理想です)。
説明文
設定項目に説明文を付与したい場合には、11pt(Smallサイズ相当)のフォントを適用したラベルで該当項目のすぐ下に配置します。カラーはSecondary Label相当にすると良いでしょう。
ハイパーリンクを埋め込む場合には、属性付き文字列でリンク部分を下線なしの青色にして、Webブラウザにジャンプできるようにします。
(例:Web上にあるプライバシーポリシー文書を示す場面など)
Safariの設定ウインドウに見られる、説明文の例。
グループ化とセパレータ(区切り線)
関係する設定項目をなるべくひとまとめにし、視覚上のグループを形作ります。グループ同士の間には余白を設け、それらが島としてある程度固まって見えるようにします。基本的にはグループは横並びにはせず、縦にスタックするように並べます。一方、Grapherのようにタイル状にレイアウトすることも間違いではありません。
Font Bookの設定ウインドウ
Grapherの設定ウインドウ
グループ間に意味上の明確な差があると考えられる場合には、余白だけでなくNSBoxの横セパレータを配置し、区切り線を表現しましょう。セパレータの左右のマージンには20pt以上を確保し、ウインドウ全体を完全に仕切るのではなく、軽く区切るような見た目にします。
グループはウインドウ全体の中央に置き、見出しラベルのtrailing部分が縦に直線で揃うようにします。
チェックボックス、ラジオボタン、ポップアップボタン
設定のオンオフにはスイッチではなく、チェックボックスまたはラジオボタンを採用してください。
いくつかの属性を選ばせるような場面では、ラジオボタンの代わりにポップアップボタンも使用できます。ポップアップボタンを採用すると、選択肢が増える可能性のある対象を扱う際に、レイアウトが自由になりやすくなります。
(例:デフォルトの検索エンジンとして、Google、Yahoo、Bing、DuckDuckGoを並べる場合など)
Safariの設定ウインドウ
象徴的な設定には独自のUIを
アプリにとって何か象徴的な設定がある場合には、それを独自のカスタムUIで示すことも検討してみましょう。
Sketchの設定ウインドウ
参考資料
文献
- 設定 – HIG
- Apple Human Interface Guidelines (2004-08), Apple Computer, Inc.
- 環境設定の作法 / Manners of Preferences Window on macOS – 1024jp
- Layout Guidelines
実装
筆者が設定UIを再現実装しやすくするために、UIの基本実装をパッケージ化したものです。AppKitを想定しています。
Discussion