テスト・審査・配信

アプリは出した後にすぐ直せないので、リリース前のテストの重みが Web より大きくなります。ただし、画面を動かすテストは遅くて壊れやすいので、粒度ごとにバランスよく持ちます。

テストの粒度

テストしやすくするには、ViewModel が通信や DB を直接作らず、外から渡してもらう（DI）形にしておきます。時間や乱数も差し替えられるようにすると、結果が安定します。

アプリのビルドは時間がかかり、署名などの手順も多いので、人の手でやると間違えます。CI で自動にしておくと、誰がやっても同じ結果になります。

• プルリクエストごとに、ビルド・静的解析・単体テストを流します。UI テストは時間がかかるので、夜間やリリース前にまとめて流すこともあります。
• iOS のビルドには macOS が必要です。GitHub Actions の macOS のランナーや Xcode Cloud を使います。macOS のランナーは料金が高めなので、キャッシュで時間を短くします。
• Android はエミュレーターで UI テストを流せます（Gradle Managed Devices を使うと端末の設定もコードで書ける）。実機の幅は Firebase Test Lab などで補います。
• 署名とストアへのアップロードは fastlane などで自動化し、署名の鍵は CI のシークレットに置きます。

UI テストがたまに落ちる（フレーキー）と、誰も結果を信じなくなります。固定の待ち時間を入れず、要素が出るのを待つ書き方にし、落ちやすいテストは直すか外します。

本番に出す前に、本物の配信の仕組みで社内や一部の利用者に配って確かめます。Web の検証環境にあたるものです。

テスト配信の版は、本番と同じ署名・同じ設定（リリース版の最適化）で作るのが大事です。デバッグ版でしか確かめていないと、R8 で消えたクラスや、本番の API の設定の違いで、本番だけ落ちることがあります。

App Store も Google Play も、アプリを出す前に審査があります。審査は多くの場合1〜2日以内に終わりますが、落ちると直して出し直しになります。

審査で落ちやすい点

• 審査の人がログインできない：ログインが必要なアプリは、審査用のアカウントを申請時に渡します。
• 落ちる・作りかけ：審査中にクラッシュする、空の画面や「準備中」のボタンが残っている。
• アカウントの削除：アカウントを作れるアプリは、アプリの中から削除できるようにする必要があります（App Store）。
• 課金：アプリの中で使うデジタルの商品は、原則としてストアのアプリ内課金を使う決まりがあります（国や条件による例外が増えているので、最新の規約を確かめる）。
• 権限の説明：カメラや位置情報の許可を求める理由が書かれていない、使わない権限を求めている。
• プライバシーの申告：集めているデータとストアに書いた申告が合っていない。

修正版は審査を通り、さらに利用者が更新するまで届かないので、新しい版は一度に全員に出さないのが基本です。

不具合を見つけても、修正版は審査を通り、さらに利用者が更新するまで届きません。そこで、一度に全員に出さない段階的リリースを使います。

最初の数日はクラッシュ率や問い合わせを見て、問題があれば止めます。致命的な問題には、修正版の審査を急いでもらう申請（App Store の迅速審査）もありますが、頼り切らず、アプリの中の機能をサーバー側から止められる Feature Flag を用意しておきます。

Feature Flag は、機能を使うかどうかをアプリの更新なしにサーバー側から切り替える仕組みです。新しい機能を一部の人だけに出す、問題があったらすぐ止める（キルスイッチ）、A/B テストをする、といった使い方をします。

Remote Config など

Firebase Remote Config や、Feature Flag 専用のサービス、自社の設定 API などで配ります。使うときの注意は次のとおりです。

• アプリの中に既定値を持つ：設定を取れなかった（初回起動・オフライン）ときにも正しく動くように。
• 取りにいく間隔：毎回取りにいくと通信が増え、制限にかかることもある。キャッシュの時間を決め、「次の起動から反映」でよいものが多い。
• 画面の途中で切り替えない：使っている最中に機能が消えると混乱するので、起動時や画面を開くときに読む。
• 片付ける：全員に出し終わったフラグはコードから消す。残すと分岐が増え続ける。

セキュリティの問題や API の大きな変更で、古い版をどうしても動かせないときの最後の手段が強制アップデートです。

古い版を動かせなくなったときに備えて、「推奨する版」と「最低の版」をサーバー側に持ちます。

版の比べ方は、文字列ではなく数字ごとに比べます（"1.10.0" は "1.9.0" より新しい）。OS ごとに版の番号がずれることが多いので、iOS と Android で別々に持ちます。また、最低の版を上げるときは、その版で直したい問題が本当にあるかを確かめ、上げる前に何割の人が対象になるかを見ます。

API との付き合い方（強制アップデート）

Android では Google Play の In-App Updates を使うと、アプリの中で更新を進められます。最低の版を取れなかったとき（オフライン）に止めない作りも大事です。

アプリには、利用者に見せる版と、ストアが新旧を見分けるための番号の2つがあります。

リリースの周期は、リリーストレイン（毎週・2週ごとなど決まった日に出す）が多く使われます。準備できた機能だけを乗せ、間に合わない機能は Feature Flag で隠したまま次に回すので、「あの機能を待って全体が遅れる」ことがなくなります。リリースのブランチを切ってコードを凍結し、テストと審査の間に見つかった不具合はそのブランチで直します。

アプリでは、ログやイベントを端末から送る実装をアプリエンジニアが受け持ちます。端末は電波が切れたり、アプリがすぐ終了されたりするので、Web より「確実に送る」工夫が要ります。

アプリは一度配ると古い版が長く残るので、イベントの名前や項目を変えると、古い版と新しい版で数字が混ざります。変えるときは版を区別できる項目（アプリの版）を必ず送り、データ側と集計の仕方を決めてから出します。分担の全体は Data のログは誰が設計・実装するかにまとめています。