iOS でデザインするときにあると便利そうな知識

標準 UI 要素とカスタマイズ

標準の UI 要素としてどういうものが用意されており、どうカスタマイズできるのかについては、以下のサンプルコードがざっくりと参考になります。こういうのが非エンジニアでも分かるものが欲しい…。

UIKit Catalog (iOS): Creating and Customizing UIKit Controls

ここから大きく外れると、カスタムなコントロールの作成などが必要になってくるのですが、アプリケーションの価値は UI のデコレーションに宿るとは思っていないので、実装コストをどこに費やすか、標準 UI のちょっとしたカスタマイズで代替できないか、というところを最初によく練った方がいいと思うのですよね。

tintColor によるカスタマイズ

tintColor は UIKit が提供している UI の標準の色を変更するプロパティで、子ビューに伝搬する という特性があります。

アプリケーションのビュー階層のルートは AppDelegate で管理している window になるので、以下の1行でアプリケーション全体に適用することができます。

window?.tintColor = UIColor.blue

アプリケーションのキーカラーが決まっている場合などはこの方法に頼りたくなるのですが、思わぬところまで影響してしまったりで、実際あまり使う機会がない気がします。

Appearance Proxy によるカスタマイズ

個別の UI 要素のインスタンスではなく、そのクラスそのものに対して、まとめて外観に関わるメソッドを実行することができます。

UIButton.appearance().setBackgroundImage(image, for: .normal)

上のような処理を行うと、UIButton およびそのサブクラスを使っているすべての場所に影響が及びます。実際にはサブクラスを用意して、そこに対して実行する方が安全です。

実行時に動的に影響するため、@IBDesignable を有効活用している場合などは相性がよくないです。

UIView.appearance(whenContainedInInstancesOf: [UINavigationBar.self]).tintColor = UIColor.red

appearance(whenContainedInInstancesOf:) で影響範囲を限定することができるので、上のような指定をすると UINavigationBar だけ tintColor を設定するということができます。

pt(ポイント)と px(ピクセル)

iOS 上では pt という論理的な単位でレイアウトを扱います。1pt はデバイスのスケールに応じて 1〜3px の値になります。

scale pixel device
@1x 1px 絶滅危惧種
@2x 2px 最近の iPhone や iPhone SE は @2x
@3x 3px iPhone Plus や iPhoneX は @3x

ボーダーなどは 1pt では太すぎるため、ピクセルで指定して引きたいなどのケースがあるかと思います。pt を px に変換するには単に scale で割れば良いので実現は簡単です。

layer.borderWidth = 1 / UIScreen.main.scale

たま〜に 0.5 の固定値を入れる実装ミスを見かける気がします。

タイポグラフィ

システムフォントの日本語フォントは指定より小さくなる

大前提として、iOS には「システムフォント」というものが存在します。これは様々な言語のフォントを組み合わせたものですが、それだけではなく、視認性のために字間などの細かな調整が入っています。

このことが引き起こすよくある問題として、iOS9 以降のシステムフォントでは、和文が pt 指定通りにならない ということが挙げられます。

スクリーンショット 2018-04-07 10.45.51.png

ともに 17pt を指定していても、システムフォント側の和文が明らかに小さいのが分かるかと思います。このため、Sketch で作ったレイアウトをピクセルパーフェクトにしようとしても大抵はうまくいきません。

iOS のヒラギノ角ゴシック問題

カンプとフォントサイズが変わってしまうのを避けるため、明示的にヒラギノ指定するという手段をとるという方法を思いつくかもしれません。

しかしながら、iOS のヒラギノ角ゴシックフォントは日本語以外を表示するときに欠陥を抱えていて、たとえば単に UIButton の font に指定すると、

button.png

このようにあっさり Descent 部分が見切れてしまいます。ネットを漁るとこの手の問題に対処するべく、先人がいろいろ調査していた痕跡を見つけることができると思います。

フォントの欠陥をワークアラウンドで解消することは不可能ではないですが、やはりベストなのは iOS のシステムフォントの特性を理解した上でデザインすることかなと思います。

参考文献

テキストの配置

欧文はそこまで神経質になる必要がないのですが、和文で特に約物が絡んだりすると 5〜10px は余裕でずれるので、ピクセル一致を目指すのはかなりつらみがあります。

bounding box.png

なので、「どこのピクセルにテキストを配置するか」という情報よりも、近接している要素と、そうではない要素でどう余白を差別化するのか?というトンマナが汲み取れる方が嬉しい気がします。

余談として、Illustrator 経由で作られたっぽいカンプをトレースするのが非常に難易度が高い印象があるのですが、仮想ボディじゃなくて、字面体で bounding box を計算してたりするんでしょうか…。

入力のためのテキスト要素

UITextField や UITextView は、内部にパディングが設定されている ので、テキストの配置に使う場合は注意が必要です。

スクリーンショット 2018-04-07 12.21.14.png

UITextView であれば、textContainerInset で調整すること自体は可能です。

UITextField の場合は、サブクラスを作成して、textRect(forBounds:)editingRect(forBounds:)placeholderRect(forBounds:)の3つのメソッドをオーバーライドする必要があります。

それぞれ、入力済みのテキスト、編集中のテキスト、プレースホルダの位置を調整するものですが、プレースホルダは内部の UILabel で表示しており、縦方向にセンタリングされているので y 軸方向にパディングを設定したときの挙動が怪しいです。

スクリーンショット 2018-04-07 12.40.38.png

システムフォントの数値は固定幅ではない

何らかのポイントやタイマーの数値などを表示する場合、固定幅の方が桁数が揃って見やすい場合がありますが、iOS9 以降のデフォルトのシステムフォントでは数字もプロポーショナルで表示されます。

スクリーンショット 2018-04-07 15.31.43.png

この場合、monospacedDigitSystemFont(ofSize:weight:) を用いるか、または数字が固定幅で表示されるフォントを使用することで対応できます。

余白とデバイスの話

layoutMargin

すべての View は余白の値を持っていて、これは directionalLayoutMarginsiOS11 にて layoutMargin から変更されるらしい UPDATE: 語弊のある表現でした、コメントを参照ください)のプロパティで表されます。

デフォルトでは 8pt の余白となっており、Storyboard で constraint to margin にチェックを入れて作った制約は View の外郭ではなく、この余白と制約になるため、思った通りの位置にならない場合の原因というケースが多かったです。

Safe Area と余白

この余白は、Editor > Canvas > Show Layout Rectangle で可視化することができます。下の画像で薄い青い線で表示されているのが、View の持つ layoutMargins です。

スクリーンショット 2018-04-07 16.40.35.png

constraint to margin をチェックして、親 View の layoutMargins に対してレイアウトしていくと、このように余白の 8pt が反映されます。

このとき、iPhone X において subview が Safe Area を意識した表示になっている のが分かると思います。Safe Area 領域を活用した込み入ったレイアウトを実現したい場合に、layoutMargins の存在を頭の片隅に入れておくといいのかもしれません。

なお、この挙動は insetsLayoutMarginsFromSafeArea で切り替えることができます。

iPhone Plus の余白

iOS8 で追加された preservesSuperviewLayoutMargins プロパティというものがあります。true になっている View では、親 View の layoutMargins の値が尊重されます。

ググっても「UITableViewCell のボーダーを画面端に寄せるためのテク」くらいの情報しか出てこないので、どういう意図のプロパティなのか見えないのですが、デバイスを並べて UITableViewCell の左右の layoutMargins を見ると微妙な違いがあるので、そこから推察するに、ファブレット端末で余白を大きく取りたいために追加したのかなと思っています。

スクリーンショット 2018-04-07 16.09.30.png

iPhone X の Landscape 時の Safe Area の対応も含めると、UITableViewCell の左右の余白は、デザイナーが計算して考えるのではなく、OS の layoutMargins を尊重するという方針にした方が楽なのではという気がします。

この辺について詳しく解説してそうな記事

Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account log in.