Sign in with Appleの実装でテスト用と本番用のApple IDを使い分けるようになったのをきっかけに、他の設定値も開発中と本番配布とで切り替えられる仕組みを整えることにしました。
1. テスト用のURLを本番コードに残したまま公開しかけた
これまでは、動作確認用のテストサーバーのURLを直接コードに書いて、リリース前に手動で本番用のURLに書き換えるという運用をしていました。
let apiURL = "https://test-api.example.com" // 本番前に書き換えるある時、書き換えを忘れたままアーカイブしてしまい、審査に出す直前でようやく気づいて青ざめました。「手動で書き換える」という工程そのものが、いつか必ずミスを起こす仕組みだったのだと痛感しました。
2. Build Configurationの存在を知らなかった
調べてみると、Xcodeには「Debug」と「Release」というビルド構成があらかじめ用意されていて、これを使えばコードを書き換えずに値を切り替えられると知りました。
Xcodeでの実行（開発中）: Debug構成が使われる
アーカイブ・配布（本番）: Release構成が使われる存在は知っていたものの、単なるビルドの種類の違い程度にしか思っておらず、設定値の出し分けに使えることをこれまで意識していませんでした。
3. Info.plistのカスタムフィールドで値を切り替えた
具体的な実装方法を調べ、Build Settingsに構成ごとの値を設定し、それをInfo.plist経由でコードから読み取る方法を採用しました。
let info = Bundle.main.infoDictionary
let apiURL = info?["API_BASE_URL"]Build Settingsの画面で「Debugのときはテスト用URL、Releaseのときは本番URL」と設定しておけば、あとはXcode側がビルド時に自動で正しい値を選んでくれるようになりました。手動での書き換えという工程そのものをなくせたことが、一番の収穫でした。
4. ログ出力も条件分岐で消し忘れることに気づいた
設定値だけでなく、デバッグ用に仕込んでいたprint文についても見直しました。本番のアプリにデバッグ用のログが大量に出力されたままになっていることに気づいたのです。
#if DEBUG
print("APIレスポンス: \(response)")
#endif#if DEBUGという条件分岐を使うと、Release構成でビルドしたときにはこのコード自体がそもそも含まれなくなると知りました。「本番では動くけど無視される」のではなく「本番のバイナリに含まれもしない」という違いも理解でき、パフォーマンスやセキュリティの面でも安心感が増しました。
まとめ
- テスト用の値をコードに直接書いて手動で書き換える運用は、書き換え忘れのリスクが常につきまとう
- XcodeのDebug/Release構成を使うと、ビルドの種類に応じて自動的に設定値を切り替えられる
- Build SettingsとInfo.plistを組み合わせることで、コードを一切書き換えずに環境ごとの値を扱える
- デバッグ用のログ出力は
#if DEBUGで囲むと、本番ビルドにはそもそも含まれなくなる
一度この仕組みを整えてからは、「書き換えを忘れていないか」という不安を抱えたままリリース作業をすることがなくなりました。
本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。
コメント