Conditional Compilation nelle app mobili — essenza, direttive e principio di funzionamento

Cos'è Conditional Compilation

Conditional Compilation è un meccanismo in cui il compilatore analizza le direttive di compilazione condizionale e include nel binario di output solo i blocchi di codice le cui condizioni sono soddisfatte. Ciò consente di avere un'unica base di codice che si adatta a diverse piattaforme e configurazioni target.

Il concetto proviene dal C/C++ con le direttive di preprocessore #ifdef, #ifndef, #endif. Nei linguaggi moderni (Swift, Rust, Go), il meccanismo funziona a livello di compilatore senza un preprocessore separato, aumentando la sicurezza: i blocchi condizionali devono essere sintatticamente corretti anche se non vengono compilati.

Secondo la sessione Apple WWDC “Embrace Swift” (2025), circa il 40% dei progetti Swift utilizza la compilazione condizionale per supportare iOS e macOS in un unico target. Per i progetti con UIKit e SwiftUI, il codice dell'interfaccia utente è spesso suddiviso da direttive #if os(iOS) e #if os(macOS), consentendo il riutilizzo della logica di business.

Il vantaggio principale è la sicurezza in fase di compilazione. Il codice per una piattaforma non adatta non solo non viene eseguito, ma non viene compilato. Ciò significa che gli errori nel codice specifico per iOS non si manifesteranno durante la compilazione per macOS e viceversa. I controlli in fase di esecuzione non offrono tali garanzie.

Conditional Compilation in Swift

Swift fornisce quattro direttive chiave: #if, #elseif, #else, #endif. A differenza del preprocessore C, Swift richiede la correttezza sintattica del codice in tutti i rami — il compilatore analizza tutto il codice ma genera codice macchina solo per i rami attivi.

Controlli di piattaforma os()

Swift supporta funzioni di controllo integrate: os(iOS), os(macOS), os(tvOS), os(watchOS), os(Linux), os(Windows). Queste funzioni verificano la piattaforma target per cui l'applicazione viene compilata. La combinazione con && e || consente di creare condizioni complesse.

// Codice unificato per iOS, macOS e 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
    }
}

Controlli di versione del compilatore

Swift supporta il controllo della versione del compilatore: #if swift(>=5.9). Ciò è utile per librerie e framework che supportano più versioni di Swift. Le nuove funzionalità del linguaggio (come le macro in Swift 5.9) possono essere protette da tale controllo.

// Retrocompatibilità
#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

Controllo di disponibilità del modulo canImport()

La funzione canImport(ModuleName) verifica se il modulo specificato è disponibile nell'ambiente di compilazione corrente. Questo è il meccanismo più flessibile: non è legato a una piattaforma specifica. Ad esempio, il codice che utilizza CoreHaptics verrà compilato solo sui dispositivi in cui questo framework è disponibile.

#if canImport(CoreHaptics)
    import CoreHaptics

    class HapticManager {
        private var engine: CHHapticEngine?

        func playTapFeedback() {
            guard let engine else { return }
            // Implementazione del feedback aptico
        }
    }
#endif

Alternative in Kotlin e Android

Kotlin come linguaggio non ha direttive di preprocessore. Invece, l'ecosistema Android offre tre alternative: campi BuildConfig (controlli in fase di esecuzione), sourceSets (sostituzione di interi file) e expect/actual (in Kotlin Multiplatform).

Source Sets in Gradle

I sourceSets di Gradle consentono di avere diverse implementazioni di classi per diversi flavor o tipi di build. Nella directory src/debug/ si trova l'implementazione per il debug, in src/release/ — per il rilascio. Durante la compilazione, Gradle seleziona il sourceSet appropriato e compila solo i suoi file.

// 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 in release
    }
}

Expect/Actual in Kotlin Multiplatform

KMP fornisce il meccanismo expect (dichiarazione nel codice comune) e actual (implementazione per una piattaforma specifica). È un meccanismo in fase di compilazione: per iOS viene compilata l'implementazione actual dal sourceSet iOS, per Android — dal sourceSet Android. Le implementazioni non target non vengono compilate.

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

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

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

Preprocessore C/C++ e NDK

Nello sviluppo di librerie native tramite Android NDK, viene utilizzato il classico preprocessore C/C++ con le direttive #ifdef, #ifndef, #define. A differenza di Swift, il preprocessore C funziona a livello di testo — il codice nei rami inattivi può essere sintatticamente errato.

Flag di piattaforma NDK

NDK definisce macro per ogni piattaforma: __ANDROID__ (Android), __APPLE__ (iOS/macOS), __linux__ (Linux). Per le architetture: __arm__, __aarch64__, __x86_64__. Queste macro vengono impostate automaticamente dal compilatore durante la compilazione per la piattaforma target.

// Codice nativo per Android e 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

Quando si lavora con NDK, è importante ricordare che il preprocessore C/C++ è una sostituzione di testo. Se c'è un errore sintattico in un ramo inattivo, il compilatore non lo vedrà, ma se un #define errato rompe un ramo attivo — l'errore si manifesterà. Si consiglia di minimizzare le catene di #define e utilizzare costanti constexpr.

Per Rust, che viene anche utilizzato nello sviluppo mobile tramite UniFFI e Mozilla Application Services, esiste il suo meccanismo — i feature flags in Cargo.toml. Flag come #[cfg(target_os = “android”)] in Rust funzionano in modo simile alle direttive Swift: il controllo viene eseguito a livello di compilatore, non di preprocessore. Ciò rende Rust una scelta interessante per librerie native che devono compilare per Android e iOS da un'unica base di codice.

Scenari pratici e antipattern

Conditional Compilation è efficace in scenari strettamente definiti. Se usata in modo errato, crea code smell difficile da testare e mantenere. Esaminiamo gli scenari corretti e gli errori tipici.

Scenari corretti

Il primo scenario è l'astrazione di piattaforma: un'unica Facciata con Conditional Compilation che seleziona l'implementazione di piattaforma all'interno. Il secondo è il debug e profilazione: strumenti di sviluppo che non dovrebbero finire nella release. Il terzo è la retrocompatibilità: supporto per versioni precedenti del sistema operativo fino all'aggiornamento della versione minima.

Antipattern

L'antipattern più pericoloso è la proliferazione di direttive in tutto il codice. Se ogni secondo file contiene #if, è un segno che l'architettura necessita di refactoring. La soluzione corretta è estrarre il codice di piattaforma dietro protocolli/interfacce e utilizzare l'Iniezione di Dipendenze.

• #if in ogni file — un antipattern architetturale. Il codice di piattaforma dovrebbe essere isolato dietro protocolli.
• #if annidati — diventano rapidamente illeggibili. La profondità di annidamento non dovrebbe superare i 2 livelli.
• Duplicazione di intere funzioni — se una funzione è completamente copiata in #if e #else, dovrebbe essere estratta in una parte comune.
• Test — il codice all'interno di rami inattivi non viene testato. Sono necessarie build CI di tutte le combinazioni possibili.
• Flag magici — flag non documentati che il nuovo team di sviluppo non conosce.