本番リリース直前で止まる理由

課題
1. この記事でわかること
解決できたこと
本文

課題

開発中は何の問題もなく動いていたアプリが、いざストアへ出そうとした直前になって、次々と「実はここが未設定でした」という問題にぶつかる。テストは全部通っているのに、なぜ今になって出てくるのか分からない。

この記事でわかること

開発中は問題なかったのに、本番リリース直前で発覚しやすい落とし穴の種類
テストやLintでは検出できない設定漏れ・審査ルールをどう見つけるか

解決できたこと

「Debug環境で動く」ことと「本番リリースの準備が整っている」ことは別物だと分かった上で、テストやLintでは検出できない、本番リリース直前特有の落とし穴をどう見つけ、どう直すかの実例を紹介する。

本文

「動いている」と「出せる」は、別のチェックリストだという話

自分がAIと一緒に個人開発しているアプリを、実際にストアへ出す準備を進めていたときの話。開発中はmelos run testもflutter analyzeも全部パスしていて、エミュレータでも問題なく動いていた。それでも、本番リリースの準備を始めた途端に、これまで一度も表面化しなかった問題が次々と見つかった。

共通していたのは、どれも「ビルドは通り、開発環境では動く」タイプの問題だったこと。Dartのコード自体は正しくても、その外側にある設定ファイルや審査要件が整っていない——これは普段のテストやLintでは、原理的に検出できない種類の問題だった。

実例1: com.exampleのまま出荷しかけていた話

アプリのAndroid側のパッケージ名（applicationId）が、Flutterのテンプレートが生成する初期値（com.example.〇〇）のまま放置されていた。署名も、開発用のデバッグ鍵のまま。

これに気づかなかった理由は単純で、flutter createが生成するテンプレートには、直すべき箇所に「ここは自分の値に変えてください」というコメントが最初から入っている。ただ、これはコメントであってエラーではないので、開発中は何も困らずビルドが通り続ける。困るのはストアに出す本番ビルドを作る段になって初めて。

直し方は、パッケージ名を実際に使うものへ変更し、本番用の署名鍵を用意するだけ。ここで得た教訓はもっと汎用的で、新しいアプリを作るたびに、テンプレートに残っている「直してください」コメントを検索してから本番準備に入る、という手順を先にやることにした。

実例2: 「エラーが起きない」設計が、逆に問題を隠していた話

もう一つ見つかったのが、通知・分析ツール（Firebase）の設定ファイルが、5本のアプリ全部でAndroid側だけ用意されていなかったという話。

これがなぜ今まで発覚しなかったかというと、設定ファイルが無いまま初期化に失敗しても、コード側が「失敗したらエラーを出さずに、分析機能無しでそのまま動き続ける」という防御的な作りになっていたから。クラッシュしないという意味では正しい設計判断だけど、副作用として「設定が漏れていること自体」が一切表に出てこない。

これは単純な見落としというより、安全に倒した設計判断とのトレードオフ。「エラーで落ちない」を優先すると、「エラーで気づく」機会を失う。直すこと自体はシンプル（設定ファイルを実際に配置する）でも、気づく仕組みの方をどう作るかが本質的な課題だと分かった。

実例3: .gitignoreのせいで、iOS対応した分がまるごと消えていた話

iOS対応で新しく生成したファイル一式（ios/フォルダ）をgit addしても、何も追加されない。おかしいと思って確認したところ、.gitignoreに元から/ios/を除外する行が残っていた。

このアプリの雛形を作った時点では、まだAndroidにしか対応していなかったので、「iOS等のネイティブフォルダは対象外」という除外設定が最初から入っていた。後になって実際にiOS対応したときに、この除外行を消し忘れると、せっかく生成したファイルがまるごとGitの管理外になる。ビルド自体は通ってしまうので、コミットする段になるまで気づけない。

これも直し方は簡単（除外行を消すだけ）だけど、忘れやすいポイントとして「新しいプラットフォームに対応したら、.gitignoreの除外設定も一緒に見直す」をチェック項目に加えた。