Swift / iOSアプリ開発では、開発中だけ実行したい処理を記述するために #if DEBUG を使う機会が多くあります。しかし、初心者の方からは次のような悩みをよく聞きます。
- Debug と Release の違いがよく分からない
#if DEBUGがどう動いているのか理解できていない- 本番アプリに Debug 用のコードが混ざらないか不安
- いつどんな処理を Debug セクションに書けばいいのか分からない
この記事では、Xcode の Debug / Release ビルド構成から #if DEBUG の仕組み、具体的な使い方、注意点までを iOSアプリ開発初心者向けにわかりやすく解説します。
Debug / Release ビルドとは？基本の仕組みを理解する
Xcode ではビルド構成として Debug と Release の2種類が標準で用意されています。
ざっくり言うと、次のような役割分担になっています。
| ビルド構成 | 説明 |
|---|---|
| Debug | 開発中向け。最適化なし・デバッグしやすい設定 |
| Release | App Store 配信用。高速化＆軽量化される設定 |
Debug ビルドの特徴
- コンパイラ最適化がオフ（
-Onone） printなどのログがそのまま出力される- ブレークポイントで変数の中身を確認しやすい
DEBUGフラグが自動定義される（後述の#if DEBUGの元になる）
Release ビルドの特徴
- コンパイラ最適化が有効（
-O）で実行速度が速い - 不要な情報が削られ、バイナリサイズが小さくなる
- デバッグ情報が少ないため中身を追いにくい
DEBUGフラグは定義されない
この「Debug では DEBUG フラグが有効、Release では無効」という違いが、#if DEBUG の挙動に直接関わってきます。
#if DEBUG とは？Xcodeが自動で設定するコンパイル条件
Debug ビルドでは、Xcode の Build Settings にある次の項目が自動的に設定されています。
- Active Compilation Conditions =
DEBUG
そのため、Swift コード内で次のように書くと、
#if DEBUG
print("Debug only message")
#endif
挙動は次のようになります。
- Debug ビルド：メッセージがコンソールに出力される
- Release ビルド：このコードは 丸ごとコンパイル対象から除外され、アプリにも含まれない
つまり、本番用のアプリには Debug 用ログやデバッグメニューが一切入らないようにできるのが #if DEBUG の大きなメリットです。
#if DEBUG を使った実用例5選
ここからは、実際の現場でよく使われるパターンを紹介します。
例1：開発中だけログを出す
#if DEBUG
print("API Response: \(response)")
#endif
Release ビルドではログが一切出力されず、パフォーマンスやセキュリティ面でも安心です。
例2：テストユーザーを自動ログイン
#if DEBUG
UserDefaults.standard.set("test-user", forKey: "userId")
#endif
毎回ログイン情報を入力する手間を省き、開発中の検証速度を上げられます。
例3：モックAPIと本番APIの切り替え
#if DEBUG
let api = MockAPI()
#else
let api = RealAPI()
#endif
開発中はモックサーバーやスタブを利用し、本番環境では実際の API を叩く、といった構成が簡単に実現できます。
例4：デバッグ用のメニューやボタンを表示
struct ContentView: View {
var body: some View {
VStack {
Text("メイン画面")
#if DEBUG
Button("デバッグメニューを開く") {
// デバッグ用の処理
}
#endif
}
}
}
Debug ビルドでのみ表示されるボタンやメニューを作ることで、開発用の隠し機能を安全に仕込むことができます。
例5：環境ごとに baseURL を切り替える
#if DEBUG
let baseURL = "http://localhost:3000"
#else
let baseURL = "https://api.example.com"
#endif
開発中はローカルサーバー、本番は商用サーバー、といった環境切り替えも #if DEBUG で簡単に管理できます。
本番では絶対に使ってはいけない Debug 用コードの注意点
便利な一方で、#if DEBUG の使い方を誤ると、「Debug では動くのに Release では動かない」というやっかいなバグの原因になります。
よくある NG パターン
- Debug のみで初期化される変数や設定を本番で前提にしてしまう
- Debug ではネットワークをスキップし、Release では本番APIを叩くが未テスト
- Debug 用の処理にロジックの一部が紛れ込み、本番ではごっそり抜ける
ポイントは、「Debug と Release で挙動が大きく変わるようなロジックは極力書かない」ことです。Debug ではログやモック差し替え程度に留めるのが無難です。
Debug / Release の切り替え方法（Xcode 操作手順）
実際に Debug / Release を切り替える方法も押さえておきましょう。
手順1：Scheme の編集画面を開く
- Xcode 左上の「再生ボタン」の右側にある Scheme 名をクリック
- Edit Scheme… を選択
手順2：Run / Archive の Build Configuration を確認
- Run：通常は Debug が選ばれている
- Archive：基本的に Release を使用（App Store 配信用）
Archive（アーカイブ）は常に Release で行うのが基本ルールです。TestFlight や App Store にアップロードされるビルドは Release だと覚えておきましょう。
独自のコンパイルフラグ（STAGING / BETA）の追加方法
開発が進んでくると、Debug / Release 以外にも「ステージング」「ベータ版」などの環境を用意したくなることがあります。その場合は、独自のコンパイルフラグを追加するのがおすすめです。
よく使われるフラグの例
STAGING：ステージング環境用BETA：ベータテスター向けビルドINTERNAL：社内用ビルド
フラグの追加手順
- Xcode のプロジェクトナビゲータで TARGET を選択
- Build Settings タブを開く
- 検索バーで「Active Compilation Conditions」を検索
- 追加したい構成（例：Debug）の欄に
STAGINGやBETAを追記
たとえば、Debug の条件を次のように設定したとします。
DEBUG STAGING
すると、Swift コード内で次のように条件分岐できます。
#if STAGING
print("Staging server enabled")
#endif
#if DEBUG と組み合わせることで、「Debug かつ STAGING のときだけ有効」といった細かい制御も可能です。
よくある質問Q&A
Q1. TestFlight ビルドは Debug ですか？ Release ですか？
A. TestFlight に配信されるビルドは Release ビルドです。つまり、#if DEBUG 内のコードは TestFlight では実行されません。
Q2. Debug 用の print は本番に残りますか？
A. #if DEBUG で囲っていれば、Release ビルドではその部分がまるごとコンパイル対象外になるため、本番アプリには含まれません。
Q3. Debug ビルドでは動くのに、本番でクラッシュするのはなぜ？
A. よくある原因のひとつが、#if DEBUG 内でしか初期化されない変数や設定を本番コードが前提としてしまっているケースです。Release ビルドではそのコードが存在しないため、nil アクセスや未設定によるクラッシュが発生することがあります。
まとめ：Debug セクションを理解すると開発効率が爆上がりする
- Xcode には Debug / Release の2つのビルド構成がある
- Debug ビルドでは
DEBUGフラグが自動定義される #if DEBUGを使うことで、開発中だけ実行されるコードを安全に書ける- Release ビルドでは Debug 用コードは完全に除外され、本番アプリには含まれない
- モックAPI・ログ・デバッグメニュー・環境切り替えなど、実用例は非常に多い
- 独自フラグ（
STAGING/BETAなど）を追加すれば、より柔軟な環境構成が可能
#if DEBUG やビルド構成を正しく理解しておくと、開発効率も品質も一気に向上します。まだ使いこなせていない方は、まずはログ出力やモックAPIの切り替えから試してみてください。
