Kompilacja warunkowa w aplikacjach mobilnych — istota, dyrektywy i zasada działania

Czym jest kompilacja warunkowa

Kompilacja warunkowa — to mechanizm, w którym kompilator analizuje dyrektywy kompilacji warunkowej i włącza do wynikowego pliku binarnego tylko te bloki kodu, dla których warunki są spełnione. Pozwala to na posiadanie jednolitej bazy kodu, która dostosowuje się do różnych platform docelowych i konfiguracji.

Koncepcja pochodzi z C/C++ z dyrektywami preprocesora #ifdef, #ifndef, #endif. W nowoczesnych językach (Swift, Rust, Go) mechanizm działa na poziomie kompilatora bez osobnego preprocesora, co zwiększa bezpieczeństwo: bloki warunkowe muszą być składniowo poprawne, nawet jeśli nie są kompilowane.

Według danych Apple WWDC Session „Embrace Swift” (2025), około 40% projektów Swift używa kompilacji warunkowej do obsługi iOS i macOS w jednym targetcie. Dla projektów z UIKit i SwiftUI kod UI jest często rozdzielony dyrektywami #if os(iOS) i #if os(macOS), co pozwala na ponowne wykorzystanie logiki biznesowej.

Główna zaleta — bezpieczeństwo na etapie kompilacji. Kod dla nieodpowiedniej platformy nie tylko nie jest wykonywany, ale nie jest kompilowany. Oznacza to, że błędy w kodzie specyficznym dla iOS nie ujawnią się podczas budowania dla macOS i odwrotnie. Sprawdzanie w czasie wykonywania nie daje takiej gwarancji.

Kompilacja warunkowa w Swift

Swift udostępnia cztery kluczowe dyrektywy: #if, #elseif, #else, #endif. W przeciwieństwie do preprocesora C, Swift wymaga poprawności składniowej kodu we wszystkich gałęziach — kompilator parsuje cały kod, ale generuje kod maszynowy tylko dla aktywnych gałęzi.

Sprawdzanie platformy os()

Swift obsługuje wbudowane funkcje sprawdzania: os(iOS), os(macOS), os(tvOS), os(watchOS), os(Linux), os(Windows). Te funkcje sprawdzają platformę docelową, dla której budowana jest aplikacja. Kombinacja z && i || pozwala tworzyć złożone warunki.

// Wspólny kod dla iOS, macOS i 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
    }
}

Sprawdzanie wersji kompilatora

Swift obsługuje sprawdzanie wersji kompilatora: #if swift(>=5.9). Jest to przydatne dla bibliotek i frameworków, które obsługują wiele wersji Swifta. Nowe możliwości języka (na przykład makra w Swift 5.9) mogą być chronione takim sprawdzeniem.

// Wsteczna zgodność
#if swift(>=5.9)
    @MainActor
    struct ModernView: View {
        var body: some View {
            Text("Nowoczesny SwiftUI")
        }
    }
#else
    struct ModernView: View {
        var body: some View {
            Text("Starszy SwiftUI")
        }
    }
#endif

Sprawdzanie dostępności modułu canImport()

Funkcja canImport(ModuleName) sprawdza, czy określony moduł jest dostępny w bieżącym środowisku budowania. Jest to najbardziej elastyczny mechanizm: nie jest powiązany z konkretną platformą. Na przykład kod używający CoreHaptics będzie kompilowany tylko na urządzeniach, gdzie ten framework jest dostępny.

#if canImport(CoreHaptics)
    import CoreHaptics

    class HapticManager {
        private var engine: CHHapticEngine?

        func playTapFeedback() {
            guard let engine else { return }
            // Implementacja odpowiedzi dotykowej
        }
    }
#endif

Alternatywy w Kotlin i Android

Kotlin jako język nie ma dyrektyw preprocesora. Zamiast tego ekosystem Android oferuje trzy alternatywy: pola BuildConfig (sprawdzanie w czasie wykonywania), sourceSets (zamiana całych plików) i expect/actual (w Kotlin Multiplatform).

Source Sets w Gradle

Gradle sourceSets pozwalają na posiadanie różnych implementacji klas dla różnych wariantów lub typów budowania. W katalogu src/debug/ znajduje się implementacja dla debug, w src/release/ — dla release. Podczas budowania Gradle wybiera odpowiedni sourceSet i kompiluje tylko jego pliki.

// 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 w trybie release
    }
}

Expect/Actual w Kotlin Multiplatform

KMP udostępnia mechanizm expect (deklaracja w kodzie wspólnym) i actual (implementacja dla konkretnej platformy). Jest to mechanizm na etapie kompilacji: dla iOS kompilowana jest implementacja actual z iOS sourceSet, dla Android — z Android sourceSet. Niepotrzebne implementacje nie są kompilowane.

// commonMain — deklaracja expect
expect fun getPlatformName(): String

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

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

Preprocesor C/C++ i NDK

Podczas tworzenia natywnych bibliotek przez Android NDK używany jest klasyczny preprocesor C/C++ z dyrektywami #ifdef, #ifndef, #define. W przeciwieństwie do Swifta, preprocesor C działa na poziomie tekstowym — kod w nieaktywnych gałęziach może być składniowo niepoprawny.

Flagi platformowe NDK

NDK definiuje makra dla każdej platformy: __ANDROID__ (Android), __APPLE__ (iOS/macOS), __linux__ (Linux). Dla architektur: __arm__, __aarch64__, __x86_64__. Te makra są ustawiane automatycznie przez kompilator podczas budowania dla platformy docelowej.

// Kod natywny dla Androida i 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

Podczas pracy z NDK ważne jest, aby pamiętać, że preprocesor C/C++ to zamiana tekstowa. Jeśli w nieaktywnej gałęzi znajduje się błąd składniowy, kompilator go nie zauważy, ale jeśli z powodu nieprawidłowego #define zepsuje się aktywna gałąź — błąd się ujawni. Zaleca się minimalizowanie łańcuchów #define i używanie stałych constexpr.

Dla Rust, który również jest używany w tworzeniu aplikacji mobilnych przez UniFFI i Mozilla Application Services, istnieje własny mechanizm — feature flags w Cargo.toml. Flagi typu #[cfg(target_os = "android")] w Rust działają podobnie jak dyrektywy Swifta: sprawdzanie odbywa się na poziomie kompilatora, a nie preprocesora. To czyni Rust atrakcyjnym wyborem dla natywnych bibliotek, które muszą być kompilowane pod Android i iOS z jednej bazy kodu.

Praktyczne scenariusze i antywzorce

Kompilacja warunkowa jest skuteczna w ściśle określonych scenariuszach. Przy nieprawidłowym użyciu tworzy kod o nieprzyjemnym zapachu, który jest trudny do testowania i utrzymania. Rozważmy poprawne scenariusze i typowe błędy.

Poprawne scenariusze

Pierwszy scenariusz — abstrakcja platformowa: jednolity fasad, wewnątrz którego kompilacja warunkowa wybiera implementację platformową. Drugi — debugowanie i profilowanie: narzędzia programistyczne, które nie powinny trafiać do wydania. Trzeci — wsteczna zgodność: obsługa starych wersji systemu, dopóki nie zostanie zaktualizowana minimalna wersja.

Antywzorce

Najbardziej niebezpieczny antywzorzec — rozprzestrzenianie dyrektyw po całym kodzie. Jeśli co drugi plik zawiera #if, to sygnał, że architektura wymaga refaktoryzacji. Prawidłowym rozwiązaniem jest wydzielenie kodu platformowego za protokoły/interfejsy i użycie Dependency Injection.

• #if w każdym pliku — antywzorzec architektoniczny. Kod platformowy powinien być izolowany za protokołami.
• Zagnieżdżone #if — szybko stają się nieczytelne. Głębokość zagnieżdżenia nie powinna przekraczać 2 poziomów.
• Powielanie całych funkcji — jeśli funkcja jest w całości skopiowana w #if i #else, należy ją wydzielić do wspólnej części.
• Testowanie — kod wewnątrz nieaktywnych gałęzi nie jest testowany. Niezbędne są CI z budowaniem wszystkich możliwych kombinacji.
• Magiczne flagi — nieudokumentowane flagi, o których nie wie nowy zespół programistów.