iOS・Android の作法

iOS には Apple の Human Interface Guidelines（HIG）、Android には Google の Material Design という公式の指針があります。OS の標準の部品や操作に合わせると、ユーザーは説明なしで使え、エンジニアも標準の部品で早く作れます。独自の部品は作る手間に加えて、アクセシビリティや OS の更新への対応も自前になります。

1つのデザインを両方の OS に使う場合も、戻る操作・アイコン・部品の細部を OS ごとに合わせるかを、最初にエンジニアと決めます。全部をそろえるとどちらの OS でも少し不自然になり、全部を分けるとデザインと実装の手間が倍になるので、「操作の作法は OS に合わせ、色・文字・情報の構成は共通」がよくある落としどころです。

ナビゲーションの違いで特に大事なのが「戻る」です。Android ではユーザーがいつでも OS の戻る操作を使うので、ダイアログやシートを開いているときに戻ると何が閉じるか、入力の途中で戻ったら確認を出すか、を決めておきます。iOS ではモーダル（全面に重なる画面）に戻るスワイプが効かない場面があるので、閉じるボタンや「キャンセル」を必ず置きます。

スマホの画面の上下（横向きなら左右）には、ステータスバー・カメラの切り欠き・ホームインジケーターなどがあります。これらを避けた範囲をセーフエリアと呼びます。

端末によって切り欠きの形や大きさは違うので、数値を決め打ちにせず「セーフエリアの内側から ○px」とデザインに書きます。Web では env(safe-area-inset-bottom) などで、端末ごとのセーフエリアの幅を受け取れます。

スマホの画面は、同じ大きさでも端末によって画素の細かさ（密度）が違います。そこで、密度に依存しない単位で大きさを決めます。

Android の sp は文字のための単位で、ユーザーのフォントサイズの設定で大きくなります。Web の CSS の px も、実際の画素ではなく論理的な単位です。デザインツールの 1px は、これらの論理的な単位の1つ分として扱うのが基本です。

日付の選択や共有のように、OS が標準で用意している画面や部品があります。標準のものを使うと、ユーザーは慣れた操作で使え、アクセシビリティや OS の更新への対応も OS に任せられます。独自に作ると、見た目は自由になりますが、作る手間と保守の手間が大きく増えます。

デザインで独自の見た目にしたいときは、「標準の部品の色や文字だけ変える」「標準の部品を使い、周りを工夫する」から検討すると、手間を抑えられます。どこまで標準に合わせるかは、プロダクトの最初にエンジニアと方針を決めておきます。

アプリエンジニア向け：端末と OS の多様性

スワイプ・長押し・つまむなどのジェスチャーは便利ですが、見えないので気づかれにくく、OS の操作とぶつかることもあります。

ジェスチャーだけでできる操作は、キーボードや支援技術を使う人には使えないことがあります。WCAG でも、複数の指や軌跡を使う操作には、1本の指で押すだけの代わりの手段を用意することが求められています。

通知・位置情報・カメラ・写真・連絡先などは、OS が出すダイアログでユーザーの許可を得ます。OS のダイアログは、見た目もボタンの文言もアプリ側では変えられません（説明文の一部だけ書けます）。

一度断られると、アプリから同じダイアログを再び出せないことが多く、ユーザーが設定アプリで変えるしかなくなります。だからこそ、最初に出す場面とその前の説明が大事です。

アプリを直してユーザーに届けるには、Web より多くの段階があります。

デザインでは、①リリース前に実機で確認する時間を計画に入れる、②お知らせ・バナーなど変わりやすい部分はサーバーから内容を変えられる形にするかを相談する、③古い版のアプリに新しい種類のデータが届いても崩れない（知らない種類は表示しない、など）ことを確かめる、の3つを意識します。