Proměnné prostředí: co to je, použití a nastavení v mobilních projektech

Co jsou proměnné prostředí

Proměnné prostředí jsou pár klíč-hodnota, přístupný procesu aplikace prostřednictvím API operačního systému. Jsou předávány procesu při jeho vytvoření a existují pouze po dobu jeho běhu. Na rozdíl od parametrů konfigurace vložených do zdrojového kódu, proměnné prostředí nevyžadují překompilování pro změnu hodnot. To je základní princip Twelve-Factor App, který zajišťuje jasné oddělení mezi kódem a konfigurací.

V mobilním vývoji proměnné prostředí řeší problém různých konfigurací pro prostředí: vývojář používá lokální server, tester používá staging, uživatelé používají produkci. Místo ukládání tří URL backendu v kódu s podmínkovými operátory if-else, vývojář předává jedno URL prostřednictvím proměnné prostředí ve fázi sestavení. To zjednodušuje kód a eliminuje riziko náhodného použití produkčního serveru v testovacím prostředí.

Hlavní výhodou je bezpečnost: citlivé údaje se nedostanou do repozitáře kódu. API klíče, Firebase tajemství, tokeny přístupu k backendu a certifikáty se načítají přes CI/CD přímo do prostředí sestavení. Pokud útočník získá přístup k repozitáři kódu, nenajde tam tajemství, protože jsou uložena v chráněných úložištích systému CI a jsou předávána pouze ve fázi sestavení binárního souboru.

Proč jsou potřebné proměnné prostředí v mobilním vývoji

Mobilní projekty mají alespoň tři prostředí: development, staging a produkci. Každé prostředí vyžaduje vlastní sadu konfigurací: URL serveru, název balíčku, schéma podepisování a certifikáty push oznámení. Bez proměnných prostředí musí vývojář ručně měnit konfiguraci před každým sestavením, což vede k chybám: zapomenutý produkční klíč v testovacím sestavení může způsobit odesílání oznámení skutečným uživatelům nebo spotřebu placeného API.

Oddělení prostředí

Proměnné prostředí umožňují přepínání backendu bez změny kódu: stačí nahradit hodnotu v proměnné API_BASE_URL. Příznaky funkčnosti (feature flags) jsou spravovány prostřednictvím proměnných jako FEATURE_CHAT_ENABLED=true, což umožňuje aktivovat nové funkce ve stagingu bez dopadu na produkci. Pro každé prostředí se vytváří vlastní .env soubor, který se načítá ve fázi sestavení.

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

Bezpečnost klíčů

Tvrde kódované klíče jsou běžnou zranitelností mobilních aplikací. Útočník dekompiluje APK nebo IPA pomocí nástrojů jako jadx nebo Hopper a extrahuje tajemství z binárního souboru. Dokonce ani obfuskace nechraní řetězcové literály — jsou snadno nalezeny v kódu po dekompilaci. Proměnné prostředí řeší tento problém tím, že předávají klíče ve fázi sestavení přes CI/CD, kde jsou maskovány v logech.

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

CI/CD integrace

Proměnné prostředí se integrují s pipeline sestavení: GitHub Actions, GitLab CI, Bitrise a CircleCI podporují tajné proměnné, které se nezobrazují v logech. Ve fázi sestavení CI dosazuje příslušné hodnoty v závislosti na větvi nebo tagu: pro vėtev develop se používá staging, pro tag v* se používá produkce. To automatizuje proces a eliminuje lidský faktor, čímž garantuje, že každé sestavení obdrží správnou sadu konfigurace.

.env soubory a knihovny pro správu

Soubor .env je standardní způsob ukládání proměnných prostředí ve formátu KEY=VALUE. Nená zahrnut do repozitáře, místo toho je do repozitáře přidán .env.example se šablonou všech proměnných a prázdnými hodnotami. Každý vývojář vytváří vlastní .env soubor s místním nastavením, aniž by ovlivňoval konfiguraci ostatních členů týmu. Pro různá prostředí se používají samostatné soubory: .env.dev, .env.stage, .env.prod.

# .env.example — šablona pro vývojáře
API_BASE_URL=http://localhost:8080
FEATURE_CHAT_ENABLED=true
SENTRY_DSN=

Pro mobilní projekty existují specializované knihovny pro práci s .env soubory:

• flutter_dotenv (Flutter) — načítá proměnné z .env za běhu pomocí dotenv.load()
• BuildConfig (Android) — generuje typovaná pole z hodnot build.gradle
• xcconfig (iOS) — připojuje konfigurační soubory k různým Xcode schématům sestavení
• react-native-config (React Native) — správa proměnných prostřednictvím .env souborů

Nastavení větve v CI/CD umožňují dosazení různých .env souborů: .env.dev pro testovací servery, .env.stage pro předvydání a .env.prod pro publikaci v obchodech s aplikacemi. Soubory s tajemstvími se načítají z bezpečného úložiště (Vault, AWS Secrets Manager) a neukládají se v repozitáři. To garantuje, že i v případě kompromitace systému pro správu verzí zůstanou tajemství chráněna.

Proměnné prostředí v iOS projektech

iOS ekosystém používá xcconfig soubory pro správu proměnných na úrovni sestavení. Ty se připojují k Xcode schématům a umožňují přepsání hodnot pro konfigurace Debug a Release. xcconfig soubory podporují dědičnost: lze vytvořit základní soubor se společným nastavením a specifické soubory pro každé prostředí.

Nastavení xcconfig souborů

xcconfig soubory ukládají proměnné ve formátu KEY = VALUE a připojují se ke schématu sestavení v Xcode pomocí nastavení Configuration. Proměnné z xcconfig jsou přístupné v Info.plist prostřednictvím syntaxe $(VARIABLE_NAME), což umožňuje použití různých identifikátorů balíčku a názvů aplikací pro různá schémata. Pro rychlou identifikaci prostředí se k názvu aplikace přidává přípona Dev nebo Staging.

# Config/Dev.xcconfig — vývojová konfigurace
API_BASE_URL = http://localhost:3000
BUNDLE_ID_SUFFIX = .dev
APP_DISPLAY_NAME = MyApp Dev

Swift kód pro čtení proměnných

Pro přístup k proměnným za běhu v iOS se používá soubor Configuration.swift, který čte hodnoty z Info.plist pomocí Bundle.main.object(forInfoDictionaryKey:). Tento přístup garantuje, že proměnné jsou určeny ve fázi sestavení a jsou k dispozici aplikaci ihned po spuštění. Hodnoty se čtou jednou při inicializaci modulu a jsou ukládány do mezipaměti pro rychlý přístup během životního cyklu aplikace.

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
    }
}

Proměnné prostředí v Android projektech

Android podporuje proměnné prostředí prostřednictvím BuildConfig — automaticky generované třídy, jejíž pole jsou definována v build.gradle souboru modulu. BuildConfig je vytvářen při kompilaci pro každý flavor a typ sestavení zvlášť. To umožňuje různé hodnoty pro debug a release bez použití podmínkových operátorů v kódu, což zvyšuje výkon a bezpečnost.

Nastavení BuildConfig polí

BuildConfig pole se nastavují pomocí buildConfigField v defaultConfig nebo v konkrétních buildTypes. Pro každé prostředí se vytváří samostatný buildType nebo productFlavor. To zajišťuje přísnou izolaci konfigurací: debug používá lokální server, release používá produkci. BuildConfig pole jsou staticky typovaná, což eliminuje chyby při odkazování v kódu.

// 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 pro společné hodnoty

Soubor gradle.properties v kořeni projektu ukládá globální Gradle proměnné. Jsou přístupné ve všech modulech pomocí syntaxe $variableName a používají se pro určení verzí závislostí, příznaků sestavení a API klíčů. Na rozdíl od BuildConfig, gradle.properties funguje pouze ve fázi konfigurace Gradle, nikoli za běhu aplikace. Proto hesla a API klíče uvedené v gradle.properties nejsou viditelné v dekompilovaném kódu, protože jsou používány pouze pro generování BuildConfig při kompilaci.

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

Pro bezpečný přenos tajemství v Android projektech se doporučuje používat local.properties (vyloučen z VCS) nebo načítat hodnoty z CI/CD proměnných do build.gradle pomocí System.getenv(). To garantuje, že klíče neproniknou do repozitáře. Při publikování v Google Play Console se ujistěte, že všechny debug klíče byly nahrazeny produkčními verzemi pomocí různých buildTypes nebo productFlavors s odpovídajícími hodnotami BuildConfig.