アプリUIデザイナーなら知っておきたい、iOSの文字が小さくなる問題
これは フェンリル デザインとテクノロジー Advent Calendar 2022 12日目の記事です。
「〇〇なら知っておきたい」なんてタイトル、我ながら「大げさだなあ」と思ってしまいます。
それでもそんなタイトルにしたのは、「iOSの文字が小さくなることを知らないままアプリのデザインに携わり、泣きを見た私みたくなってほしくない」という思いがあるからです。半年前の自分に出会えるなら、「絶対に知ってほしい」と伝えたいぐらい、これは重大な問題です。
という訳で、「iOSの文字が小さくなる問題」について、啓蒙していきたい気持ちを込めて書き記します。
「そんなことも知らなかったの？」と笑われてもいいので、私のような思いをする人間を生み出さないためにも、本当に知ってほしいと思います。
iOSの文字が小さくなる問題とは
問題の概要
一言でいうと「指定通りのフォントサイズで実装したにも関わらず、実際に仕上がったアプリでは日本語の文字が小さく表示されてしまう」という問題です。
何と比較して小さくなるの？ というと、デザインツールで作成したデザインカンプです。例えば、デザイン作成時に17pxで指定していた文字が、実装されると16pxぐらいの大きさになってしまいます。全体的に、おおよそ1px小さくなってしまうのです。
実際に見比べてみよう
言葉ではイメージしづらいと思うので、実際のiOSの「設定」画面のスクリーンショットと、デザインツールSketchを使って作成したカンプを並べて見てみましょう。
カンプは、Appleが提供するデザインリソースを使用して作成しているので、同じパーツを使用していれば、理論上は実装画面と同じになるはずです。ところが、そうはなりません。
パッと見た時点で「右のほうが文字が少し小さいな」という印象を抱きませんでしたか？ もう少し拡大して比較してみましょう。
何気に右側にあるシェブロンの位置も違いますが、iPhoneSEサイズに横幅を調整した影響が残ってしまったようなので、今回は無視してください。
どうでしょうか？ 上下並べて比べるとやはり下（実際のアプリ）の方が小さいです。
厳密に比べてみても、やはり小さくなっているようです（注1）。
上記の画像は１パーツのみの比較ですが、画面全ての文字が1px違うと、かなり印象に差が出てしまいます。わざわざ横に並べて比較しなくても「なんだか思ったより文字が小さいな？」と誰もが思ってしまうぐらいです。
カンプと向き合った時間が長ければ長いほど、違和感は強く出てしまいます。
もちろんカンプを共有し、一緒にデザインについて議論を深めてきたクライアントも気づきます。
問題が起こる原因
文字が小さくなってしまう原因について要約すると、iOSシステムフォントであるSF Proは、アルファベットと日本語を並べた時のバランスをとるため日本語の文字サイズを小さく調整しているからです。これはOSで設定されている、変えようのない仕様です。
詳細はここでは割愛しますが、詳しく知りたい方はこちらのサイトに分かりやすく解説されているので、個人的におすすめです。
問題の対応策
さて、この記事の目的は達成できました。「実装すると文字が小さくなる」、ひとまずこれだけ知って、持って帰ってもらえれば、かつての私の無念は報われるというものです。
事前に知りさえすれば、実装されたアプリを見ても「きちんと指定通りに実装してもらったのになぜ文字が小さいんだろう。デザインデータが間違っている？ 実装があるべき姿？ デザインと実装されたアプリ、どちらを正解とすべきだろうか？」と絶望することもありません。
とはいえ「文字が小さくなるんだなあ」で納得して帰る人はいないでしょう。知りたいのはその先「どうやったらこの問題を回避できるのか？」のはずです。
この問題は残念ながら、SF proの日本語フォントがリリースされない限りは根本的な解決は見込めません。しかし、問題を最小限に抑えるための方法はいくつかあります。これから、そのうちの４つを紹介します。
対策１：「文字が小さくなるもの」と受け入れる
「デザインカンプ上の文字は、実装後小さくなるのだ」、と受け入れる方法です。
一見、デザイン再現の放棄にも見えますが、決して投げやりではありません。
もし、これがポスターや紙モノのデザインであれば、文字の大きさの再現は非常に重要な問題になるでしょう。
レイアウトを考え抜き、まさしくこれだという文字の大きさを決めたのに、印刷したら小さくなっている、なんてことがあれば、デザインの検討なんて不可能です。
しかし、アプリのUIデザインは違います。なぜなら、Human Interface Guidelines (HIG) に、文字の大きさの模範解答が載っているからです。
つまり、HIGに則ってデザインすれば究極のところ、文字の大きさの検討は不要なのです。
デザインカンプ上の文字と、実装後の文字の大きさが一致しなかったとしても、正解の大きさはHIGに掲載されています。
HIGのタイポグラフィの通りに、見出し・文章の文字サイズを指定しておけば、Apple純正アプリと同じ大きさの文字で仕上がります。
「実装後は小さくなるんだ」というのを念頭に置いたうえで、粛々とHIGの数字を反映すればいいのです。
この方法は、例えば自社アプリ開発のように、チームメンバーがこの問題を共有し、HIGを経典とすることに全員が理解を示す場合に、最も効果的でしょう。
【対策１のまとめ】「文字が小さくなるもの」と受け入れる
自社開発向け（HIGやiOSへの高いリテラシーが必要）
メリット：最もコストがかからない
デメリット：HIGの例外への対応が難しい。HIGは日本語のタイポグラフィに最適化されている訳ではない。
対策２：デザインデータを２種類用意する
しかし、クライアントワーク、とりわけウォーターフォール型の場合はそうはいきません。
クライアントに依頼されてアプリ開発をする場合、デザインカンプは開発チームメンバー内だけのものではなくなります。
このときのデザインカンプは、クライアントにアプリの最終形をイメージしてもらうための資料となります。つまりクライアントにとっての「正解の見た目」になるのです。
デザインカンプが正解の見た目だと思っていたクライアントが、実装後のアプリを見て文字が小さくなっていることに気づくと、どう思うでしょうか。
当然、カンプの文字の大きさに合わせてほしい、と思うに違いありません（注２）。
そこで第２の対策「デザインデータを２種類用意する」です。
開発チームと共有するデザインデータとは別に、クライアント向けにあらかじめ文字を1px小さくしたデザインデータを用意するのです。
こうすれば、クライアントは実装アプリと同じ文字サイズのカンプを確認することができます。「正解の見た目」が、まさしく実装アプリと同じになるわけです。
この方法はデータの二重管理になってしまうため、デザイナーの負担が大きくなってしまうのがデメリットです。
一方で、iOS標準のライブラリを使用した時の、画面の文字サイズを完全再現できる唯一の方法でもあります。
のちのち「デザインカンプに合わせて、OS標準ライブラリの文字サイズを変更する」という悲しい相談を、開発チームにする必要がなくなるのは大きいです。
【対策２のまとめ】デザインデータを２種類用意する
クライアントワーク（ウォーターフォール型）向け
メリット：確実に実装後の画面を再現できる
デメリット：データの二重管理になりコスト大
対策３：実装時に1px大きくしてと伝える
実装すると小さくなるなら、あらかじめ、1px大きな数字で実装すればどうでしょうか？
つまり「デザインデータ上は17pxとなっているけど、実装するときは18pxにしてね」と開発チームに伝えるのです。
伝え方は単純です。デザインツールとは別に「フォント指示資料」を用意してフォントサイズの指定を羅列したものを共有するのです。
「正解はフォント指示資料にある」と連携できれば、開発チームが迷うこともありません。現在、私はこの方法を採用しています。
ただこの方法もいくつかデメリットがあります。
私の担当案件の場合、フォントサイズ以外の実装情報（マージンなど）は、デザインツール上で管理をしていて、開発チームもそちらを参照しています。
デザインツールとフォント指示資料、二つを見比べなければいけないという点ではネックです。
それでも、UI設計書に注釈を追加するだけでOK、と考えれば、進行中の案件に対しても導入しやすい対策と言えます。
【対策３のまとめ】：実装時に1px大きくしてと伝える
クライアントワーク（ウォーターフォール型）向け
メリット：進行中案件に導入しやすい
デメリット：参照しなければならない実装情報が増える
対策４：デザインツール内に実装指示を記す
これが一番スマートな方法です。「実装時にフォントを1px大きくしてね」という指示を、デザインツール上から閲覧できるようにします。
デザインツール内のコメントに残したり、オブジェクトの名称を「iOS-18px」など直接指示を書き込むなどが考えられます（参考：UIデザイナーに必要なiOSのTypographyの知識）。
ただし、この方法はデザインデータを作り始める初期から、ルールを決めて運用する必要があります。
現在進行形の案件なら、名称を付け直したり、データを差し替えをしなければいけません。
まさしく、「文字が小さくなる問題」を事前に知っていなければできない対策です。
【対策４のまとめ】デザインツール内に実装指示を記す
クライアントワーク向け
メリット：二重管理の手間が最も小さい
デメリット：進行している案件に導入する場合はそれなりに手間
まとめ
まず「iOSで実装されたアプリの文字は小さくなる問題」を知ることが大事です。HIGにも掲載されていない言わば隠し仕様なので、まず知るだけで十分なアドバンテージとなります（知らない時のデメリットが大きすぎるという意味でもあります）。
これを知った人はぜひ、チームメンバーや後輩に広めてみてください。それだけで助かる人が増え、無駄なコストがカットされ、ひいては日本のアプリ開発業界が元気になること間違いなし、と私は信じています。
また、問題自体を知れれば、対策を立てられます。
自分が携わる案件の特性や、進行度に応じて打つ手が変わってくるので、現状に応じて対策を講じましょう。
また、デザインツールによってはこの問題を解決するための、便利なプラグインもあるようなので、探してみるのも一手です（Sketchにはなさそうです……）。
【余談】そもそもカンプと実装の文字サイズを一致させる必要ってあるの？
ここまで、iOSのアプリをデザインする上で、知っておくべき大きな問題を紹介しましたが、そもそも「実装時の見た目を完璧にデザインカンプで再現する」という思想自体が、UIデザインには即していないのかもしれません。
UIデザインの肝は、あらゆるデバイスで、かつさまざまな表示設定（アクセシビリティ設定）下で、同一の情報を得られるように設計することにあります。
流動的に変化するデザインがアプリケーションのUIデザインだと見なすなら、ただ一枚の静止したカンプに状態を固定して、検討すること自体無理があるのかもしれません。
こうなると、「設計（ワイヤーフレーム）→デザイン→実装」というフローではなく、「設計→実装⇔デザイン」というフローが、アプリ開発の理想形と言えそうです。
デザインしながら同時に実装していく。デザイナーが、デザインと実装（あるいはプロトタイプ実装）の両方を対応するのです。
このような理想の制作フローは、自社開発はともかく、ウォーターフォール型のクライアントワークではなかなか難しそうだな、と想像しています。とはいえ、どうにか落としどころを探っていきたいところです。
（注１）この問題が発生する条件は２つあります。１つは「SF proを指定していること」、もう１つは「日本語の文字であること」です。条件が限られているとはいえ、SF proはiOSのシステムフォント。iOSアプリをデザインする場合は、ほぼ必ず使うことになるものです。
（注２）クライアントに、事前に「実装後は文字が少し小さくなります」と伝えておく手もありますが、文字が小さくなるのを想像しながらカンプを確認してもらうのは非常に難しいでしょう。
（注３）実装後の動作テストの段階で、一つずつ指摘して修正してもらう方法があります。が、これは二度手間ですし、正解の数字がどこにも残らず、開発チーム内でメンバーの引継ぎがあったときに面倒が生じてしまうのでやめましょう（ちなみに、私はこの方法で乗り越えざるを得ませんでした）。