Umgebungsvariablen: Was sie sind, Verwendung und Konfiguration in mobilen Projekten

Was sind Umgebungsvariablen

Umgebungsvariablen sind Schlüssel-Wert-Paare, die über die Betriebssystem-API für den Anwendungsprozess zugänglich sind. Sie werden dem Prozess bei seiner Erstellung übergeben und existieren nur während seiner Laufzeit. Im Gegensatz zu Konfigurationsparametern, die in den Quellcode eingebettet sind, erfordern Umgebungsvariablen keine Neukompilierung, um Werte zu ändern. Dies ist ein grundlegendes Prinzip der Twelve-Factor App, das eine klare Trennung zwischen Code und Konfiguration gewährleistet.

In der mobilen Entwicklung lösen Umgebungsvariablen das Problem unterschiedlicher Konfigurationen für verschiedene Umgebungen: Der Entwickler verwendet einen lokalen Server, der Tester verwendet Staging und die Benutzer verwenden die Produktion. Anstatt drei Backend-URLs mit if-else-Bedingungen im Code zu speichern, übergibt der Entwickler eine URL über eine Umgebungsvariable zur Build-Zeit. Dies vereinfacht den Code und beseitigt das Risiko, versehentlich den Produktionsserver in einer Testumgebung zu verwenden.

Der Hauptvorteil ist die Sicherheit: Sensible Daten gelangen nicht in das Code-Repository. API-Schlüssel, Firebase-Geheimnisse, Backend-Zugriffstoken und Zertifikate werden über CI/CD direkt in die Build-Umgebung geladen. Wenn ein Angreifer Zugriff auf das Code-Repository erhält, findet er dort keine Geheimnisse, da diese in geschützten Speichern des CI-Systems aufbewahrt und nur in der Build-Phase der Binärdatei übergeben werden.

Warum Umgebungsvariablen in der mobilen Entwicklung wichtig sind

Mobile Projekte haben mindestens drei Umgebungen: Entwicklung, Staging und Produktion. Jede Umgebung benötigt ihren eigenen Satz an Konfigurationen: Server-URL, Paketname, Signaturschema und Push-Benachrichtigungszertifikate. Ohne Umgebungsvariablen muss der Entwickler die Konfiguration vor jedem Build manuell ändern, was zu Fehlern führt: Ein vergessener Produktionsschlüssel in einem Test-Build kann das Senden von Benachrichtigungen an echte Benutzer oder den Verbrauch einer kostenpflichtigen API verursachen.

Umgebungstrennung

Umgebungsvariablen ermöglichen das Umschalten des Backends, ohne den Code zu ändern: Ändern Sie einfach den Wert in der Variablen API_BASE_URL. Feature-Flags werden über Variablen wie FEATURE_CHAT_ENABLED=true verwaltet, wodurch neue Funktionen in Staging aktiviert werden können, ohne die Produktion zu beeinträchtigen. Jede Umgebung hat ihre eigene .env-Datei, die zur Build-Zeit geladen wird.

class AppConfig {
  static final String apiBaseUrl =
    const String.fromEnvironment('API_BASE_URL',
      defaultValue: 'http://localhost:8080');
}

Schlüsselsicherheit

Hartcodierte Schlüssel sind eine häufige Sicherheitslücke in mobilen Anwendungen. Ein Angreifer dekompiliert APK oder IPA mit Tools wie jadx oder Hopper und extrahiert Geheimnisse aus der Binärdatei. Selbst Verschleierung schützt Zeichenfolgenliterale nicht — sie sind nach der Dekompilierung leicht im Code zu finden. Umgebungsvariablen lösen dieses Problem, indem sie Schlüssel zur Build-Zeit über CI/CD übergeben, wo sie in Protokollen maskiert werden.

object Config {
    val apiKey: String =
        System.getenv("API_KEY") ?: throw
            IllegalStateException("API_KEY not set")
}

CI/CD-Integration

Umgebungsvariablen integrieren sich mit Build-Pipelines: GitHub Actions, GitLab CI, Bitrise und CircleCI unterstützen geheime Variablen, die nicht in Protokollen angezeigt werden. Zur Build-Zeit setzt CI die entsprechenden Werte je nach Branch oder Tag ein: Für den Develop-Branch wird Staging verwendet, für den v*-Tag die Produktion. Dies automatisiert den Prozess und eliminiert den menschlichen Faktor, sodass jeder Build den richtigen Konfigurationssatz erhält.

.env-Dateien und Verwaltungsbibliotheken

Die .env-Datei ist eine Standardmethode zum Speichern von Umgebungsvariablen im KEY=VALUE-Format. Sie wird nicht in das Repository aufgenommen; stattdessen wird .env.example mit einer Vorlage aller Variablen und leeren Werten hinzugefügt. Jeder Entwickler erstellt seine eigene .env-Datei mit lokalen Einstellungen, ohne die Konfigurationen anderer Teammitglieder zu beeinträchtigen. Für verschiedene Umgebungen werden separate Dateien verwendet: .env.dev, .env.stage, .env.prod.

# .env.example — Vorlage für Entwickler
API_BASE_URL=http://localhost:8080
FEATURE_CHAT_ENABLED=true
SENTRY_DSN=

Für mobile Projekte gibt es spezialisierte Bibliotheken für die Arbeit mit .env-Dateien:

• flutter_dotenv (Flutter) — lädt Variablen zur Laufzeit aus .env über dotenv.load()
• BuildConfig (Android) — generiert typisierte Felder aus build.gradle-Werten
• xcconfig (iOS) — verbindet Konfigurationsdateien mit verschiedenen Xcode-Build-Schemata
• react-native-config (React Native) — Variablenverwaltung über .env-Dateien

Branching-Einstellungen in CI/CD ermöglichen das Einsetzen verschiedener .env-Dateien: .env.dev für Testserver, .env.stage für Vorabveröffentlichungen und .env.prod für die Veröffentlichung in App-Stores. Dateien mit Geheimnissen werden aus einem sicheren Speicher (Vault, AWS Secrets Manager) geladen und nicht im Repository gespeichert. Dies stellt sicher, dass Geheimnisse selbst bei Kompromittierung des Versionskontrollsystems geschützt bleiben.

Umgebungsvariablen in iOS-Projekten

Das iOS-Ökosystem verwendet xcconfig-Dateien zur Verwaltung von Variablen auf Build-Ebene. Sie werden an Xcode-Schemata angehängt und ermöglichen das Überschreiben von Werten für Debug- und Release-Konfigurationen. xcconfig-Dateien unterstützen Vererbung: Sie können eine Basiskonfiguration mit gemeinsamen Einstellungen und spezifische Dateien für jede Umgebung erstellen.

Konfiguration von xcconfig-Dateien

xcconfig-Dateien speichern Variablen im KEY = VALUE-Format und werden über die Configuration-Einstellungen an ein Build-Schema in Xcode angehängt. Variablen aus xcconfig sind in Info.plist über die Syntax $(VARIABLE_NAME) verfügbar, was unterschiedliche Bundle-Identifikatoren und App-Namen für verschiedene Schemata ermöglicht. Zur schnellen Identifizierung der Umgebung wird dem App-Namen das Suffix Dev oder Staging hinzugefügt.

# Config/Dev.xcconfig — Entwicklungskonfiguration
API_BASE_URL = http://localhost:3000
BUNDLE_ID_SUFFIX = .dev
APP_DISPLAY_NAME = MyApp Dev

Swift-Code zum Lesen von Variablen

Für den Laufzeitzugriff auf Variablen in iOS wird die Datei Configuration.swift verwendet, die Werte aus Info.plist über Bundle.main.object(forInfoDictionaryKey:) liest. Dieser Ansatz garantiert, dass Variablen zur Build-Zeit definiert werden und der Anwendung sofort nach dem Start zur Verfügung stehen. Werte werden einmalig bei der Modulinitialisierung gelesen und für den schnellen Zugriff während des gesamten Anwendungslebenszyklus zwischengespeichert.

enum AppEnvironment {
    static var apiBaseURL: URL {
        guard let urlString = Bundle.main
            .object(forInfoDictionaryKey: "API_BASE_URL"),
              let url = URL(string: urlString as! String)
        else { fatalError("API_BASE_URL is not configured") }
        return url
    }

    static var isChatEnabled: Bool {
        Bundle.main.object(
            forInfoDictionaryKey: "FEATURE_CHAT_ENABLED"
        ) as? Bool ?? false
    }
}

Umgebungsvariablen in Android-Projekten

Android unterstützt Umgebungsvariablen über BuildConfig — eine automatisch generierte Klasse, deren Felder in der build.gradle-Datei des Moduls definiert werden. BuildConfig wird zur Kompilierzeit für jeden Flavor und Build-Typ separat erstellt. Dies ermöglicht unterschiedliche Werte für Debug und Release ohne Verwendung von Bedingungsoperatoren im Code, was die Leistung und Sicherheit verbessert.

Konfiguration von BuildConfig-Feldern

BuildConfig-Felder werden über buildConfigField in defaultConfig oder in bestimmten buildTypes festgelegt. Für jede Umgebung wird ein separater buildType oder productFlavor erstellt. Dies gewährleistet eine strikte Konfigurationsisolierung: Debug verwendet einen lokalen Server, Release die Produktion. BuildConfig-Felder sind statisch typisiert, was Fehler beim Zugriff im Code eliminiert.

// build.gradle (Module: app)
android {
    defaultConfig {
        buildConfigField "String", "API_BASE_URL",
            "\"http://localhost:8080\""
    }
    buildTypes {
        debug {
            buildConfigField "String", "API_BASE_URL",
                "\"http://dev.api.itsectr.com\""
        }
        release {
            buildConfigField "String", "API_BASE_URL",
                "\"https://api.itsectr.com\""
        }
    }
}

gradle.properties für gemeinsame Werte

Die Datei gradle.properties im Projektstamm speichert globale Gradle-Variablen. Sie sind in allen Modulen über die Syntax $variableName verfügbar und werden zur Angabe von Abhängigkeitsversionen, Build-Flags und API-Schlüsseln verwendet. Anders als BuildConfig funktioniert gradle.properties nur in der Gradle-Konfigurationsphase, nicht zur Laufzeit der Anwendung. Daher sind Passwörter und API-Schlüssel, die in gradle.properties angegeben sind, im dekompilierten Code nicht sichtbar, da sie nur zur Generierung von BuildConfig zur Kompilierzeit verwendet werden.

# gradle.properties
SENTRY_DSN=https://key@sentry.io/project
MAPS_API_KEY=AIzaSy...

Für die sichere Übertragung von Geheimnissen in Android-Projekten wird empfohlen, local.properties (aus VCS ausgeschlossen) zu verwenden oder Werte aus CI/CD-Variablen in build.gradle über System.getenv() zu laden. Dies stellt sicher, dass Schlüssel nicht in das Repository gelangen. Stellen Sie bei der Veröffentlichung in der Google Play Console sicher, dass alle Debug-Schlüssel durch Produktionsversionen über verschiedene buildTypes oder productFlavors mit entsprechenden BuildConfig-Werten ersetzt werden.