■ そもそもの問題
このアプリはスマホを基準に作っていたため、問題文や選択肢の表示幅が固定でした。CanvasScalerの設定上、iPadでは文字が大きく表示されるだけで、1行に入る文字数はスマホと同じ。結果として、iPadの広い画面を持て余している状態でした。
「iPad用に別画面を作るべきか？」とも考えましたが、調べてみると、多くのネイティブアプリは専用画面を持たず、1つのレイアウトを画面幅に応じて可変にする方式（iOSでいうAuto Layout + Size Classのようなもの）を採っていることが分かりました。一覧＋詳細のような2カラム構成にする意味がないアプリ（今回のような1問ずつ読むタイプ）では、これで十分だという結論です。
■ 対応範囲を絞った
今回手を入れたのは「問題を解く画面」のうち、文字量が多く画面を圧迫しやすい2画面だけです。一覧系の画面（回一覧、科目一覧など）は、これまでスマホの画面幅を前提にレイアウトを組んでいたため、そのまま同じ仕組みを適用すると、要素間の余白などが間延びした見た目になってしまいます。
■ 採った方針
・本文（問題文・選択肢）の表示幅に上限を設け、画面が広い端末ではその上限まで広げる
・上限はiPad程度の横幅で頭打ちにする
・スマホ相当の画面幅では、これまでと完全に同じ挙動のまま変えない
・ヘッダー・フッターも、押すもの（ボタン）は大きさを変えず、読むもの（背景バー等）だけ本文と同じ幅に揃える
・画像も本文の幅に追従させ、小さい画像は拡大して表示する
「上限を設けずに幅いっぱいまで広げる」という案もありましたが、それだと1行が長くなりすぎて逆に読みにくくなります。書籍の1行が40字程度に収まっているのと同じ理屈で、上限を設けることにしました。
■ 実装の考え方
肝になるのは、画面の横幅を見て「広げるべきかどうか」を毎フレーム判定する、小さな共通の仕組みです。画面の横幅がある一定のしきい値を超えたときだけ、本文の幅を上限まで広げる、というシンプルな判定にしました。
このしきい値の設定がポイントで、世の中のスマホの縦横比がどれだけ多様であっても、スマホの画面幅がそのしきい値を超えることはまずありません。結果として、スマホ側の挙動には一切影響を与えずに済みました。
あとはUnityのレイアウト機能（Vertical Layout Group）側で、子要素が親の幅の変化に追従するように設定を変更して回るという、Inspector作業が中心でした。地味な作業ですが、この手の変更はコードよりInspectorの設定漏れの方が事故のもとになります。
■ 結果
・スマホでの見た目・挙動は一切変更なし
・iPad・大型タブレットでは、本文の幅が広がり、1行あたりの文字数が大きく増加
・Galaxy Z FoldやiPhone Duoのような折りたたみ端末も、開いた状態ではこの仕組みがそのまま活きる（閉じた状態は画面が細長いため対象外とした）
横向きへの対応（Android 16以降、大画面端末では向きの固定指定が効かなくなる）についても検討しましたが、こちらは「読みにくければ端末を回せば済む」という判断で見送りました。実際、分割画面やデスクトップウィンドウ以外では、ユーザー側で簡単に解決できる話です。無理に全対応を狙わず、効果とコストの見合うところで線を引くのも大事だと思います。