iOSアプリ内で画像のユーザーガイドを提供したいと思ったが、10言語以上にローカライズする予定があり、方針をいくつか検討した。

xcassetsを使った場合、ローカライズリソース全てがバイナリサイズに含まれてしまう問題があることを理解した。その上で方針としては、下記の3つがある。

1. xcassetsに埋め込み

App Thinning後にx3のpng画像が1枚250KBだとすると50枚(5枚で1つのガイド・10ガイドあると想定) 12.5MB, 10言語分で125MBもの容量になってしまい、多言語対応をしてユーザーガイドを丁寧に書くほどアプリのサイズが大きくなってしまう。(軽量なツールアプリなのにインストールに150MBを超えるとかだと良さが失われる。) ただし、アプリのインストールさえ済んでいればネットワーク接続がなくてもガイドが見られるメリットはある。オフラインヘルプ。

2.xcassets + On Demand Resource

ja/enなどの言語ごとのフォルダを作って、その配下にユーザーガイドのリソースを置き、xxx-jaなどの言語コード付きタグを活用して、適切な言語のオンデマンドリソースだけ読み込めるようにする。この方法は通常のAssetsへのアクセスのように記述でき、必要なローカライズリソースしか読み込まなので良いが、オンディスクへの保存が要求されるため、ネットワーク接続 + 十分な容量(言語ごとに⚪︎MB)が利用条件となる。

3. サーバーに画像を置く + キャッシュ

サーバーの言語ごとのリソースディレクトリに対して、Localizable.stringsで定義した特殊な言語コード文字列を使ってNukeのLazyImageなどでアクセスする。キャッシュをしながらも、ディスク容量が不足していてもオンメモリで画像の提供が可能であり、ネットワーク環境さえあれば利用できる。ただし、Nuke分の3 ~ 4MBのバイナリサイズ増加になる。

ガイド項目をテキスト + 画像の構成にしておいて、テキストはアプリ内のLocalizable.stringsで定義し、画像だけサーバーから読み込むようにしておけば、最悪ネット接続がない環境でもテキストガイドは読めるので、ある程度の情報提供は成立する。

4. そもそもオンラインヘルプにする

これなら何も考えなくて良いが、ブラウザに飛ばずにヘルプやガイドが見られるのは個人的には体験が良く感じるので、アプリ内でなんとかやりくりできる設計を考えたい。

AsyncImageは画像のキャッシュをする/しない、で両方の意見があり、肯定派は「URLSession.sharedを使っていると言っているのだから当然URLCacheも使われるだろうしキャッシュされるだろう」、否定派は「実際に試してみたら毎回送受信が行われたので使われていない」というものだった。個人的な感想としては、URLSessionのキャッシュ挙動はCache-Control HeaderやETagによって変わるはずなので、サーバー側の設定に従ってキャッシュする可能性はある。 と思いながら、

(実際にサーバー側でCache-Control Headerをmax-age 86400に設定してXcodeのDebug Navigatiorのネットワーク画面で実験してみたが、AsyncImageでは実行のたびにネットワーク接続が発生していた。NukeではちゃんとURLCacheを使ってHTTPのCahce-Control HeaderやETagに従って行うキャッシュレイヤーがあるので、2回目以降は送受信が発生せずに画像の表示に成功した。)

アプリケーション側でキャッシュ挙動をコントロールしたい要件、もしくはそうするのが楽ちんだという場合は結構あり、NukeやKingfisherだとアプリ側のキャッシュコントロールを実現できるので、後者の場合に適しているとも思う。

ただし、NukeのDataCacheはttlの仕組みがないので、どのみちサーバー側でのキャッシュコントロールの仕組みは必要だと思う。

XServerを契約して使っているが、サービスの機能であるブラウザキャッシュをオンにしているとCache-Control Headerに1週間を設定してくれるので、まぁそれでいいかとなった。ユーザーガイドは更新頻度が極めて低いと思われるので、十分。