Konfigurationsmanagement in der mobilen Entwicklung: was es ist, welche Optionen es gibt und wie man es einrichtet

Konfigurationsmanagement in Android: Build Variant und build.gradle

Build Variant — eine Kombination aus Build Type (debug/release/staging) und Product Flavor (free/paid, demo/full). Gradle erstellt automatisch einen variant für jede Kombination: freeDebug, freeRelease, paidDebug, paidRelease. Jeder variant kann eigenen Code, Ressourcen und Abhängigkeiten haben — dies ist die Grundlage des Konfigurationsmanagements in mobilen Apps unter Android.

Build Variant vs Product Flavor

Build Type — Build-Einstellungen: ob Debugging aktiviert ist, Signierung, ProGuard-Optimierung. debug enthält standardmäßig debuggable=true, release — minifyEnabled=true.

Product Flavor — App-Variante: kostenlos (free), kostenpflichtig (paid), Demo (demo). Flavors können unterschiedliche applicationId, Ressourcen und SDK-Abhängigkeiten haben.

// build.gradle — Konfiguration von Produkt-Flavors in Android
android {
    productFlavors {
        free {
            applicationId "com.example.app.free"
            versionName "1.0-free"
        }
        paid {
            applicationId "com.example.app.paid"
            versionName "1.0-paid"
        }
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt')
        }
    }
}

Das Beispiel erstellt zwei Flavors: free und paid. Für free ist eine separate applicationId festgelegt — dies ermöglicht die Installation beider Apps auf einem Gerät. BuildConfig wird für jeden variant generiert: BuildConfig.FLAVOR = "free", BuildConfig.BUILD_TYPE = "debug". Verwenden Sie BuildConfig im Code für bedingte Logik.

settings.gradle und Gradle KTS

settings.gradle — die root Gradle-Datei, die die Projektmodule beschreibt.

Gradle KTS — eine Alternative zu Groovy mit Kotlin DSL. KTS bietet Autovervollständigung in Android Studio und Typprüfung. Für neue Projekte empfohlen.

Konfigurationsmanagement in iOS: Scheme und .xcconfig

Konfigurationsmanagement in iOS basiert auf Scheme — einer Xcode-Konfiguration, die festlegt, was und wie gebaut wird: Build Configuration (Debug/Release), Tests, Analyse, Archivierung. Schemes können für verschiedene Umgebungen (Development, Staging, Production) dupliziert werden. Schemes werden in .xcscheme-Dateien im Ordner xcshareddata gespeichert.

.xcconfig-Dateien

.xcconfig — eine Xcode-Konfigurationsdatei, die Build-Einstellungen in Textform speichert. Für das Konfigurationsmanagement mobiler Apps verwendet iOS .xcconfig: Versionierung in Git, Wiederverwendung zwischen Projekten, weniger manuelle Einstellungen. In .xcconfig werden SWIFT_ACTIVE_COMPILATION_CONDITIONS, PRODUCT_BUNDLE_IDENTIFIER, CODE_SIGN_IDENTITY festgelegt.

Info.plist — die Metadatendatei der App. Sie speichert Version, Identifikator, Berechtigungen. Info.plist kann für jedes Scheme unterschiedlich sein — über Info.plist File in Build Settings.

AndroidManifest.xml — das Android-Äquivalent: speichert Berechtigungen, Komponenten, Metadaten.

Scheme vs Build Configuration

Scheme — das Build-Szenario (was zu tun ist). Build Configuration — der Satz von Einstellungen (wie es zu tun ist). Ein Scheme verwendet eine Build Configuration (Debug oder Release). Für CI/CD: Konfigurieren Sie die Archive-Aktion auf Release und die Test-Aktion auf Debug in einem Scheme.

Konfigurationsmanagement in Flutter und React Native: pubspec.yaml, Podfile, .env

pubspec.yaml — die Konfigurationsdatei des Flutter-Projekts. Enthält Abhängigkeiten, Versionen, Ressourcen. Unterstützt Umgebungsvariablen über --dart-define.

Podfile — der CocoaPods-Abhängigkeitsmanager für iOS. Definiert Bibliotheksversionen und Plattform.

.env — eine Datei mit Umgebungsvariablen für alle Plattformen. Flutter und React Native verwenden einen anderen Ansatz für das Konfigurationsmanagement: dart-define in Flutter, react-native-config in React Native. Das Konfigurationsmanagement in plattformübergreifenden Projekten umfasst je nach Stack unterschiedliche Tools.

.env und Umgebungsvariablen

.env — eine Textdatei mit Schlüssel=Wert-Paaren. Wird nicht in Git committet (zu .gitignore hinzufügen). Für Flutter — flutter_dotenv, für iOS — Config.xcconfig mit #include, für Android — BuildConfig. env-Variablen: API_URL, SENTRY_DSN, APP_SECRET. Im Konfigurationsmanagement der mobilen Entwicklung ist .env der De-facto-Standard zum Speichern von Geheimnissen außerhalb des Repositoriums.

Podfile und pubspec.yaml

Podfile beschreibt CocoaPods-Abhängigkeiten und Plattform (platform :ios, '15.0'). pubspec.yaml für Flutter — dependencies und dev_dependencies. Beide unterstützen bedingte Abhängigkeiten: pod 'Analytics', :configs => ['Release'] oder flutter pub add --flavor free. Bei IT Sectr verwenden wir .env + BuildConfig für Geheimnisse und Podfile für native Abhängigkeiten in mobilen Projekten.

Die Tabelle zeigt die wichtigsten Unterschiede im Konfigurationsmanagement zwischen mobilen Plattformen. Android bietet mehr Flexibilität durch Build Variant. iOS ist einfacher, aber weniger flexibel. Flutter zentralisiert die Konfiguration in dart-define, aber native Abhängigkeiten erfordern weiterhin die Konfiguration von Podfile/build.gradle.

Bedingte Kompilierung im Konfigurationsmanagement

Bedingte Kompilierung — Ein- oder Ausschließen von Code zur Kompilierzeit in Abhängigkeit von Flags. Dies ist Teil des Konfigurationsmanagements: Es ermöglicht das Einbetten von Debug-Tools (Logging, Inspector) in Debug-Builds und das Entfernen aus Release. Die Implementierung unterscheidet sich zwischen den Plattformen.

Bedingte Kompilierung in Swift

#if DEBUG — Swift-Präprozessordirektive. Der Code innerhalb des Blocks wird nur in der Debug-Konfiguration kompiliert. Andere Flags: #if !RELEASE, #if targetEnvironment(simulator). Active Compilation Conditions in Build Settings — fügen Sie benutzerdefinierte Flags über -D FLAG_NAME hinzu. Das Konfigurationsmanagement von Builds durch Kompilierungsbedingungen ist in iOS Standardpraxis.

Bedingte Kompilierung in Kotlin

BuildConfig.DEBUG — boolesches Feld, true im Debug-Build. BuildConfig wird automatisch von Gradle generiert. Für benutzerdefinierte Flags verwenden Sie buildConfigField in build.gradle: buildConfigField "boolean", "REPORT_CRASHES", "true". Im Code: if (BuildConfig.REPORT_CRASHES) { ... }.

Bedingte Kompilierung in Flutter

dart-define — Flutter-Kompilierungsflags: flutter run --dart-define=ENV=staging. Im Code: const env = String.fromEnvironment('ENV', defaultValue: 'production'). Für bedingte mobile App-Builds verwenden Sie das build_runner-Plugin mit Codegenerierung.