トクバイのiOSアプリの開発を担当している松田です。
なんと！トクバイアプリが3/6にリリースしたv6.25.0でiPadに対応しました 🎉🎉🎉
そこでこの記事では画面数のそれなりに多い（のかなと私は思っています）トクバイiOSアプリのiPad対応を短期間でどのように、そしてどこに注力して対応したのか、また苦労した点などについてご紹介したいと思います。
トクバイサービスとiPad対応の背景について
ロコガイドではトクバイサービスのKPIとしていくつかの指標を追っています。
その中でも私が所属するトクバイサービス開発本部サービス開発部ではユーザーへの価値提供の指標としてUUやMAU、そしてモバイルアプリにおいてはダウンロード数などを計測しています。
なお、先日トクバイアプリは1000万DLを突破しました 🎉🎉🎉
ところが、モバイルアプリはこれまでiPadには未対応でした。
そのためユーザーからは「チラシをiPadの大きな画面で見たい」「普段iPadを横向きで利用している」「外ではiPhoneやAndroid、家ではiPadを利用している」といったご意見やご要望を度々頂いていました。
改めてiPadでの利用ユーザー状況を精査したところ、トクバイアプリでのiPhoneに対するiPad利用比率が他社と比べて思っている以上に少ないことがわかり、潜在的なiPadユーザーを取り込むことで、利用ユーザー数やアクティブユーザー数の向上を見込めそうだと判断し、今回のiPad対応のプロジェクトが発足されました。
対応方針の決定
iPad対応をすることが決まったので、次に対応方針を決めました。
前節で述べたように、潜在的なiPadユーザーがいることは間違いなさそうですが、実際にどのくらいのユーザー数増加を見込めるかはiPad対応版をまずは世にリリースしてみないとわかりません。
そこで今回の対応においては「ユーザーにiPadならではの新しい体験を提供できること」をゴールに据えつつ、ミニマムに対応することにしました。
したがって、iPad固有の機能を使うような改修までは行わずに、主にレイアウト周りの改修に留めることにしました。
一方、トクバイのiOSアプリのソースコードは日々増減してますが、レイアウトに関わるビュー関連のソースコードとして、おおよそUIViewControllerベースのファイルが90ファイル、UIViewベースのファイルが370ファイルほど存在します。
限られた期間の中でこれらの画面をどのように対応していくのか、まずは各画面の表示頻度、つまりPV数をもとに優先度を決めました。
iOSアプリでは表示された画面であるUIViewController名をログで送信しており、そのログから主要画面や多く表示される画面を把握することができます。
それを参考に優先度を付け、さらに改修コストと比較して各画面をどこまで詳細に対応するのかといった対応内容を決めました。
最終的に対応内容は以下の3パターンに決定しました。
- レイアウト変更対応
- フォントのみ対応
- 対応不要
次からそれぞれの具体的な中身について説明します。
レイアウト変更対応
この対応ではデザイナーがiPad用にレイアウトを見直し、レイアウトの実装にも変更を加えます。
基本的にはコンポーネントのサイズや比率の調整、画面におけるコンテンツの余白の調整を行います。
その際、iPadを縦に持っても横に持っても違和感のないサイズとバランスに調整し、ベースとなる比率を確認します。
そして全画面を同じ比率にするのではなく、各画面におけるコンテンツの役割や見栄えを考慮しながら各画面毎に最適な比率を決定し、各画面に反映していきました。
しかし、もちろん上記の対応内容は基本方針であり、余白の調整だけでは不十分だと判断した画面に関してはレイアウトの構成自体を変更して組み直しました。
フォントのみ対応
この対応ではレイアウトの変更や修正は行わず、iPadの大きな画面で気持ちよく文字が読めるようにフォントサイズのみ調整します。
対応内容としてはiPhoneとは別にiPad用のフォントサイズを新しく定義して、各画面のフォントに適用していきます。
ところで、トクバイのモバイルアプリでは去年(2022年)の7月にデザインシステムを適用しました。
このデザインシステム対応において、各画面ではフォントサイズは具体的な数値を指定するのではなく、相対的なスケールを表すトークン値を指定する方式に変更しました。
そして指定されたトークン値を実際の具体的な数値に変換してUIFontに適用しています。
つまり事前にこのようなデザインシステム対応をしていたおかげで、今回の対応では各画面でフォントサイズを一つずつiPad用の数値に修正することなく、トークン値を具体的な数値に変換しているロジックの箇所だけにiPad用のフォントサイズを設定するだけの対応で済みました。
しかし、実はそれだけで終わり、とはなりません。
トクバイのiOSアプリではレイアウトにxibファイルを利用しています。
ところが、結果的にはデザインシステムの対応漏れにはなるのですが、一部のフォントサイズ指定についてxibファイル上で実際の数値を設定したままになっているファイルがまだ多数残っていました。
そこで直接フォントサイズを設定しているxibファイルからswiftファイルにアウトレットを繋ぎ、コード上でトークン指定に差し替えていく作業を行いました。
つまり正直なところ、フォントのみ対応は主にこの作業が大きな対応内容ということになりました。
対応不要
こちらは基本的にフォントサイズの変更を含め、何も対応しません。
当たり前と言えば当たり前ですがWebView画面がこれに当たります。
その他では、普段ほとんど見られることがない画面やサービスが提供する本質的な機能ではない画面、例えばアプリで使用しているライブラリのライセンス画面がこれに当たります。
実装開始
対応方針を上記の3パターンに決定し、各画面をそれぞれのパターンに振り分け実装を開始しました。
まずはフォントのみ対応から着手しました。
一方で並行してレイアウト変更対応のためのサイズや比率を決める必要があるため、主に優先度の高い主要画面について先行してレイアウト変更対応も進め、デザイナーとレビューを交えながらベースとなるサイズ比率を決定しました。
そしてフォント対応が終わり次第、そのベースとなる比率をもとに残りのレイアウト変更に着手し、そこでも画面毎にデザイナーにレビューしてもらい、さらに最適なサイズに落とし込む作業を繰り返しながら対応していきました。
苦労した点
対応方針を3パターンに分け対応内容もシンプルな方法に落とし込みましたが、やはり実際にはいくつか苦労した点がありました。
ここでは自分が携わった範囲内でのものになりますが、特に苦労した点をご紹介したいと思います。
固定サイズのビュー
例えば固定文言だけを表示するビューであったり、アイコンのようなパーツ的なビューについては、これまでアプリ自体がiPhoneのみを対象としていたこともあり、当然iPhoneに最適化された固定値を用いて実装されていました。
しかし、今回のiPad対応によりiPad用にiPhoneより大きなフォントサイズを適用したことで文字が潰れてしまう、画面に収まらなくなる、さらにはレイアウトそのものが崩れてしまいました。
一方で画面構成としてレイアウト崩れは起きてないが、iPadの大きな画面に対してのコンテンツのサイズ感に違和感を感じるレイアウトになっていることもありました。
例えば端末サイズに比例した割合を設定してレイアウトを組んでいた商品画像が大きくなりすぎることで、ファーストビューを全て占領してしまい、スクロールしないと説明を見ることができない、という問題が生じました。それとは逆にコンテンツがiPadの大きな画面に対して小さくなりすぎて目的の訴求ができなくなってしまっているという状況も起こりました。
それらについては、単純にiPad用に別の固定値を指定することで解決したものもありますが、レイアウトを改めて組み直すことで対応しました。
ポップアップ形式のモーダル画面
当初、ポップアップ形式で表示している画面についてはレイアウト変更対応はせず、フォントのみ対応としていました。
しかし実際にiPadで操作してみると大きな画面かつそこでの一連の動きの中で窮屈に感じられることが多くあり、特にポップアップ表示上でビューのサイズが異なる画面に切り替わるようなケースにおいては、iPadのような大きな画面では視線の移動やボタンを押す際の手の移動など操作性が損なわれると感じられることもありました。
それらについては、デザイナーがポップアップにおけるベースとなるレイアウトルールを定め、それに則ってレイアウトを組み直しました。
UICollectionViewCompositionalLayoutを利用してカルーセルレイアウトを組んでいた画面
トクバイのiOSアプリではいくつかの画面でUICollectionViewCompositionalLayoutを利用してレイアウトを組んでいます。
その中にはカルーセル形式のレイアウトのものもあり、NSCollectionLayoutSectionのorthogonalScrollingBehaviorを利用して実装していました。
一方、これまで述べてきた通り、今回のiPad対応においては画面内のコンテンツに対して左右に余白を付ける対応方針にしていました。
具体的に説明するとUICollectionViewは画面のフルサイズで配置し、そこに表示するコンテンツのNSCollectionLayoutSectionやNSCollectionLayoutItemのcontentInsetsで余白を調整するという対応になります。
しかし、このorthogonalScrollingBehaviorにはscrollInsets的な余白を追加するAPIがないため、カルーセルの余白もしくはスクロール領域を調整できず、必ずUICollectionViewの両端までがスクロール領域になってしまいます。
そのためカルーセルレイアウトのコンテンツと通常のグリッドレイアウトのコンテンツの表示領域に差分が生まれることになり、違和感のあるレイアウトとなってしまいました。
そこで泣く泣くこのorthogonalScrollingBehaviorを利用したカルーセルレイアウトは諦め、これまで通りのUICollectionView in UICollectionViewCellによるカルーセルレイアウトの実装に作り変えました。
そしてこれにより、セルの表示(willDisplay系)やタップ(didSelectItem系)イベントのハンドリングが大元のUICollectionViewのitemではなく、UICollectionViewCell内のUICollectionViewのitemに変わるため、レイアウト変更による実装の修正はもとより、例えば画面遷移やユーザーの行動ログの実装箇所も全て修正する必要がありました。
もしこのorthogonalScrollingBehaviorを利用した場合に、スクロール領域をカスタマイズする方法を御存知の方がいらっしゃいましたらご教授頂けると幸いです。
まとめ
当初iPad対応すると決まった時にどれだけ改修するのか、期間内に終わるのかと心配でしたが、プロダクトマネージャーがしっかり対応スコープを区切り、スケジュールや改修コストを考慮した対応方針を決めてくれたため、期限内に無事対応を終え、リリースすることができました。
そしてデザイナーさんの試行錯誤のもと、必要最小限のレイアウト調整だけで当初期待していた「チラシが見やすい」「商品やレシピが映える」といったiPadでの体験やコンテンツに見合った画面を実現できたと感じています。
実装面では良くも悪くもいくつかのソースコードに手を入れることになり、結果的にレイアウト周りのリファクタができました。特にxibファイルでのAutoLayoutの制約であったり、またカスタムUIViewについてNSLayoutConstraintで縦横幅を固定して指定していたものをintrinsicContentSizeでコンテンツ内容に見合ったサイズに可変になるように変更もしました。
また今回のQAで全画面をチェックしたことで普段の開発では滅多にアクセスしない画面の既存バグを見つけ、合わせて修正することができました。
一方で、ここまでの内容でお読み頂いた方の中には気になる点があった方もいるかもしれませんが、いくつかの課題も見つかりました。
まずiPad端末なのかiPhone端末なのかの判定ロジックが至るところに組み込まれてしまいました。これはデザインの制約などもありSize Classなどを利用するだけでは不十分のため、今の時点では致し方ないとは思っていますが、より柔軟なレイアウトを組めるような方法を模索していきたいと思います。
また上記にも関連しますが、iOSアプリは現時点でDynamic Typeに明確には対応できていません。こちらはiPad対応有無に関係なく、アクセシビリティ全体の課題として今後の対応を検討していきます。
そして今回のiPad対応では前述したような理由もあり、iPadOSもしくはiPadとしての独自機能やレイアウトは組み込まず、余白の調整に留めたことでiPadの大きな画面といったポテンシャルをまだ十分には活かすまではいきませんでした。
これらの課題については、まずは今回のiPad対応におけるユーザー数へのインパクトや利用状況を計測、分析し、会社の事業へのインパクトも見極めながら対応していきたいと思います。
