モバイルアプリにおける条件付きコンパイル — 本質、ディレクティブ、動作原理

条件付きコンパイルとは

条件付きコンパイルは、コンパイラが条件付きコンパイルディレクティブを解析し、条件を満たすコードブロックのみを出力バイナリに含めるメカニズムです。これにより、異なるターゲットプラットフォームや構成に適応する単一のコードベースを維持できます。

この概念はC/C++のプリプロセッサディレクティブ#ifdef、#ifndef、#endifに由来します。現代の言語（Swift、Rust、Go）では、このメカニズムは個別のプリプロセッサなしでコンパイラレベルで動作し、安全性が向上します。条件付きブロックは、コンパイルされない場合でも構文的に正しい必要があります。

Apple WWDCセッション「Embrace Swift」（2025）によると、約40%のSwiftプロジェクトが単一ターゲットでiOSとmacOSをサポートするために条件付きコンパイルを使用しています。UIKitとSwiftUIを使用するプロジェクトでは、UIコードは#if os(iOS)および#if os(macOS)ディレクティブで分割されることが多く、ビジネスロジックの再利用が可能になります。

主な利点はコンパイル時の安全性です。不適切なプラットフォームのコードは実行されないだけでなく、コンパイルもされません。つまり、iOS固有のコードのエラーはmacOS用にビルドするときに現れず、その逆も同様です。ランタイムチェックではそのような保証はできません。

Swiftでの条件付きコンパイル

Swiftは4つの主要ディレクティブを提供します：#if、#elseif、#else、#endif。Cプリプロセッサとは異なり、Swiftはすべてのブランチでコードの構文上の正確性を要求します — コンパイラはすべてのコードを解析しますが、アクティブなブランチに対してのみマシンコードを生成します。

プラットフォームチェック os()

Swiftは組み込みのチェック関数をサポートしています：os(iOS)、os(macOS)、os(tvOS)、os(watchOS)、os(Linux)、os(Windows)。これらの関数は、アプリケーションがビルドされているターゲットプラットフォームを確認します。&&と||との組み合わせにより、複雑な条件を作成できます。

// iOS、macOS、tvOS向けの統一コード
import Foundation

class PlatformService {
    func getSystemVersion() -> String {
        #if os(iOS) || os(tvOS)
            return UIDevice.current.systemVersion
        #elseif os(macOS)
            let vers = ProcessInfo.processInfo.operatingSystemVersion
            return "\(vers.majorVersion).\(vers.minorVersion)"
        #else
            return "unknown"
        #endif
    }
}

コンパイラバージョンチェック

Swiftはコンパイラバージョンチェックをサポートしています：#if swift(>=5.9)。これは複数のSwiftバージョンをサポートするライブラリやフレームワークに便利です。新しい言語機能（Swift 5.9のマクロなど）は、このようなチェックで保護できます。

// 後方互換性
#if swift(>=5.9)
    @MainActor
    struct ModernView: View {
        var body: some View {
            Text("Modern SwiftUI")
        }
    }
#else
    struct ModernView: View {
        var body: some View {
            Text("Legacy SwiftUI")
        }
    }
#endif

モジュール利用可能性チェック canImport()

canImport(ModuleName)関数は、指定されたモジュールが現在のビルド環境で利用可能かどうかを確認します。これは最も柔軟なメカニズムです：特定のプラットフォームに縛られません。例えば、CoreHapticsを使用するコードは、このフレームワークが利用可能なデバイスでのみコンパイルされます。

#if canImport(CoreHaptics)
    import CoreHaptics

    class HapticManager {
        private var engine: CHHapticEngine?

        func playTapFeedback() {
            guard let engine else { return }
            // 触覚フィードバックの実装
        }
    }
#endif

KotlinとAndroidでの代替手段

Kotlin言語にはプリプロセッサディレクティブがありません。代わりに、Androidエコシステムは3つの代替手段を提供します：BuildConfigフィールド（ランタイムチェック）、sourceSets（ファイル全体の置き換え）、およびexpect/actual（Kotlin Multiplatform）。

GradleのSource Sets

GradleのsourceSetsを使用すると、異なるフレーバーやビルドタイプに対して異なるクラス実装を持つことができます。src/debug/ディレクトリにはデバッグ実装が、src/release/にはリリース実装があります。ビルド時に、Gradleは適切なsourceSetを選択し、そのファイルのみをコンパイルします。

// src/debug/kotlin/com/example/Logger.kt
object Logger {
    fun log(tag: String, message: String) {
        Log.d(tag, message)
    }
}

// src/release/kotlin/com/example/Logger.kt
object Logger {
    fun log(tag: String, message: String) {
        // リリースでのNo-op
    }
}

Kotlin MultiplatformのExpect/Actual

KMPはexpectメカニズム（共通コードでの宣言）とactual（特定のプラットフォームでの実装）を提供します。これはコンパイル時のメカニズムです：iOSの場合はiOS sourceSetからactual実装がコンパイルされ、Androidの場合はAndroid sourceSetからコンパイルされます。対象外の実装はコンパイルされません。

// commonMain — expect宣言
expect fun getPlatformName(): String

// androidMain — Android用actual
actual fun getPlatformName(): String =
    "Android \${Build.VERSION.SDK_INT}"

// iosMain — iOS用actual
actual fun getPlatformName(): String =
    UIDevice.current.systemName() + " " + UIDevice.current.systemVersion

C/C++プリプロセッサとNDK

Android NDKを通じてネイティブライブラリを開発する場合、#ifdef、#ifndef、#defineディレクティブを持つ従来のC/C++プリプロセッサが使用されます。Swiftとは異なり、Cプリプロセッサはテキストレベルで動作するため、非アクティブなブランチのコードは構文的に正しくない可能性があります。

NDKプラットフォームフラグ

NDKは各プラットフォームのマクロを定義します：__ANDROID__（Android）、__APPLE__（iOS/macOS）、__linux__（Linux）。アーキテクチャ用：__arm__、__aarch64__、__x86_64__。これらのマクロは、ターゲットプラットフォーム用にビルドするときにコンパイラによって自動的に設定されます。

// AndroidとiOS向けのネイティブコード
#include <cstdint>

#ifdef __ANDROID__
    int32_t getJniEnv(JNIEnv* env) {
        return env->GetVersion();
    }
#elif defined(__APPLE__)
    #include <TargetConditionals.h>
    int32_t getOsVersion() {
        #if TARGET_OS_IOS
            return "iOS";
        #elif TARGET_OS_OSX
            return "macOS";
        #endif
    }
#endif

NDKを使用する際、C/C++プリプロセッサはテキスト置換であることを覚えておくことが重要です。非アクティブなブランチに構文エラーがあってもコンパイラはそれを認識しませんが、誤った#defineがアクティブなブランチを壊すとエラーが現れます。#defineチェーンを最小限に抑え、constexpr定数を使用することをお勧めします。

UniFFIやMozilla Application Servicesを通じてモバイル開発でも使用されるRustには、独自のメカニズムがあります — Cargo.tomlのフィーチャーフラグです。#[cfg(target_os = “android”)]のようなRustのフラグは、Swiftディレクティブと同様に機能します：チェックはプリプロセッサではなくコンパイラレベルで実行されます。これにより、Rustは単一のコードベースからAndroidとiOS用にコンパイルする必要があるネイティブライブラリにとって魅力的な選択肢となっています。

実践的なシナリオとアンチパターン

条件付きコンパイルは厳密に定義されたシナリオで効果的です。誤って使用すると、テストと保守が困難なコードスメルを生み出します。正しいシナリオと典型的な間違いを見てみましょう。

正しいシナリオ

最初のシナリオはプラットフォーム抽象化です：内部で条件付きコンパイルがプラットフォーム実装を選択する単一のファサード。2つ目はデバッグとプロファイリング：リリースに含めるべきでない開発者ツール。3つ目は後方互換性：最小バージョンが更新されるまでの古いOSバージョンのサポート。

アンチパターン

最も危険なアンチパターンはコード全体へのディレクティブの蔓延です。2つおきのファイルに#ifが含まれている場合、それはアーキテクチャのリファクタリングが必要な兆候です。正しい解決策は、プラットフォームコードをプロトコル/インターフェースの背後に抽出し、依存性注入を使用することです。

• すべてのファイルに#if — アーキテクチャ上のアンチパターン。プラットフォームコードはプロトコルの背後に分離する必要があります。
• ネストされた#if — すぐに読みにくくなります。ネストの深さは2レベルを超えてはいけません。
• 関数全体の重複 — 関数が#ifと#elseで完全にコピーされている場合、共通部分に抽出する必要があります。
• テスト — 非アクティブなブランチ内のコードはテストされません。可能なすべての組み合わせのCIビルドが必要です。
• マジックフラグ — 新しい開発チームが知らない、文書化されていないフラグ。