.env File i mobilutveckling: vad är det, syfte och funktionsprincip

Vad är .env File och varför behövs det

.env File är en konfigurationsfil där miljövariabler lagras i ett enkelt textformat KEY=VALUE. Varje rad innehåller en variabel: nyckelns namn och dess värde separerade med ett likhetstecken.

.env-filer löser ett grundläggande problem inom modern utveckling: olika miljöer (lokal, test, produktion) kräver helt olika inställningar. API-serverns URL på den lokala maskinen är http://localhost:8080, på produktionsservern — https://api.production.com. Om dessa värden är hårdkodade direkt i applikationskoden kräver varje bygge för en annan miljö ändring av källkoden.

Praxis att lagra konfiguration utanför applikationens huvudkod standardiserades i manifestet The Twelve-Factor App (2011), som pekade ut miljövariabler som det enda korrekta sättet att konfigurera en applikation. Enligt JetBrains Developer Ecosystem-undersökningen (2024) använder mer än 67% av mobilutvecklarna .env-filer i sina projekt.

För mobilutveckling ger .env en extra fördel: värden ersätts i byggfasen via Gradle (Android) eller xcconfig (iOS), vilket möjliggör separata byggen för utveckling, staging och produktion utan att ändra källkoden.

.env är särskilt användbart vid teamarbete: varje utvecklare skapar sin egen lokala .env med inställningar för sin miljö (sökväg till lokal databas, debug API-nycklar), och gemensamma inställningar registreras i .env.example i repositoryt. Detta eliminerar situationen när efter git pull en utvecklares bygge går sönder på grund av en miljövariabel som hen inte kände till. En ny teammedlem kopierar helt enkelt .env.example till .env och fyller i sina lokala värden.

Syntax och struktur för .env File

.env-formatet är extremt enkelt: varje rad är en variabel i formen KEY=VALUE. Mellanslag runt likhetstecknet ignoreras vanligtvis, men i de flesta bibliotek betraktas de som en del av värdet, så det är bättre att undvika dem.

Grundläggande skrivregler

Kommentarer börjar med #-tecknet — hela raden efter det ignoreras. Tomma rader hoppas också över. Om värdet innehåller mellanslag omges det av dubbla eller enkla citattecken.

# Huvudsakliga miljöinställningar
APP_NAME=MyMobileApp
APP_ENV=development

# API-konfiguration
API_BASE_URL=http://localhost:3000/api
API_TIMEOUT=30000

# Känslig data
DB_PASSWORD=secret_password_123
JWT_SECRET=your_jwt_secret_key

Värdetyper och escapning

Alla variabler i .env är strängar, men inläsningsbibliotek kan konvertera dem till önskad typ. För escapning av specialtecken används backslash och citattecken. Om värdet innehåller #-tecknet som en del av texten måste det escapes som \#.

• Strängar — utan citattecken eller inom citattecken: KEY=value eller KEY="value with spaces"
• Tal — skrivs utan citattecken: PORT=8080
• Booleska värden — true/false-strängar: DEBUG=true
• Flervåniga — backslash i slutet av raden: KEY=line1\
line2
• Substitution — i vissa parsers: DB_URL=${DB_HOST}:${DB_PORT}

Vid inläsning av .env kan bibliotek utföra variabelinterpolation — ersätta värden från en nyckel inuti en annan. Till exempel kommer variabeln DATABASE_URL=postgres://${DB_USER}:${DB_PASS}@localhost/db att expandera DB_USER och DB_PASS från samma fil.

Integrering av .env File i mobilprojekt

Sättet att ansluta .env beror på plattformen. Android använder Gradle-plugins, iOS — xcconfig-konfigurationsfiler, och plattformsoberoende lösningar som Flutter — specialiserade bibliotek.

Android och Gradle: konfigurera BuildConfig

I Android laddas .env via pluginprogrammet gradle-dotenv. Pluginprogrammet läser .env från projektets rot och lägger till värden i BuildConfig, varefter de är tillgängliga i Kotlin- eller Java-kod via genererade fält.

// build.gradle.kts (app level)
plugins {
    id("co.uzzu.dotenv") version "4.0.0"
}

android {
    buildFeatures {
        buildConfig = true
    }
}

kotlin {
    // Åtkomst i kod: BuildConfig.API_BASE_URL
    buildConfigField("String", "API_BASE_URL",
        "\"" + dotenv.get("API_BASE_URL") + "\"")
}

iOS och Xcode: ansluta Config

I iOS konfigureras miljövariabler vanligtvis via xcconfig-filer. För att ladda .env i Swift används biblioteket DotEnv eller den inbyggda mekanismen Info.plist med anpassade nycklar.

// Ladda .env i Swift-projekt
import DotEnv

struct AppConfig {
    static func load() {
        let env = DotEnv(Bundle.main)
        env.load()

        let apiURL = ProcessInfo.processInfo
            .environment["API_BASE_URL"] ??
            "https://default.api.com"
    }
}

Flutter och Dart: flutter_dotenv-biblioteket

För Flutter finns paketet flutter_dotenv som laddar variabler från .env under applikationens initiering. .env-filen placeras i projektets rot, och variablerna blir tillgängliga via klassen dotenv.

// pubspec.yaml
dependencies:
  flutter_dotenv: ^5.1

// main.dart — laddning vid start
import 'package:flutter_dotenv/flutter_dotenv.dart';

void main() async {
  await dotenv.load(fileName: '.env');
  var apiUrl = dotenv.get('API_BASE_URL');
  runApp(MyApp(baseUrl: apiUrl));
}

Alla tre tillvägagångssätten delar en gemensam princip: .env laddas i byggfasen eller vid applikationens start, värden cachas och används i kod via genererade konstanter. Detta förhindrar att känslig data hamnar i repositoryt.

För React Native används paketet react-native-config, som i byggfasen automatiskt genererar BuildConfig-klassen för Android och konstanter i Info.plist för iOS från en enda .env-fil i projektets rot. Detta är särskilt bekvämt för startups som använder Expo eller bare workflow: en .env på rotnivå räcker, och alla plattformar får samma miljövariabler utan duplicering av konfigurationer.

Säkerhet och bästa praxis för .env File

Trots alla fördelar är .env ingen fullständig lösning för lagring av hemligheter i produktionsmiljö. Det ger en grundläggande skyddsnivå, men vid felaktig användning kan det leda till läckage av konfidentiell data.

Skydd via .gitignore

Den viktigaste regeln — .env får aldrig hamna i versionshanteringssystemet. Filen läggs till i .gitignore omedelbart efter skapandet, och endast exempelfilen .env.example med tomma eller fiktiva värden commitas till repositoryt.

# .env.example — commitad till repository
APP_NAME=
APP_ENV=development
API_BASE_URL=http://localhost:3000
API_TIMEOUT=30000
# DB_PASSWORD — ange inte ens i exemplet!
# JWT_SECRET — ange inte ens i exemplet!

# .gitignore
# Dotenv-filer
.env
.env*.local

Alternativ för produktionsmiljö

För produktionsprojekt rekommenderas professionella lösningar för hemlighetshantering. .env i produktion är endast tillåten om filen finns utanför serverns document-root och har strikta åtkomsträttigheter.

• AWS Secrets Manager — molnlagring av hemligheter med nyckelrotation och åtkomstgranskning
• Google Secret Manager — Google Cloud-tjänst för lagring av API-nycklar och lösenord
• HashiCorp Vault — verktyg med dynamiska hemligheter och kryptering på serversidan
• Firebase Remote Config — molnkonfiguration med A/B-testning för mobilapplikationer
• GitLab CI/CD Variables — inbyggd lagring av hemligheter för byggpipelines

Enligt Snyk State of Open Source Security (2024) var läckage av .env-filer via repositories orsaken till mer än 12% av alla incidenter med exponering av API-nycklar bland de tillfrågade företagen. Användning av en separat hemlighetshanterare kan minska denna risk till noll.

Ytterligare skydd uppnås genom implementering av pre-commit hooks med verktyg som husky och lint-staged, som kontrollerar om utvecklaren av misstag lagt till .env i commiten. Verktyg som git-secrets (AWS) och talisman skannar varje commit efter mönster av API-nycklar, tokens och lösenord och blockerar commiten vid upptäckt. För CI-pipelines rekommenderas att lägga till en detect-secrets-kontroll — en automatisk skanner som inte låter .env-filen komma in i repositoryt även vid ett utvecklarfel.