Implementing Environment Switcher (Dev/Staging/Prod Switching) in Mobile Apps
A developer tests a feature against the dev server, a QA engineer checks staging before release, support reproduces a user's bug with prod data — all without rebuilding the app. Environment Switcher is not a DevOps tool, it's a discipline of mobile development.
Why Hardcoded URLs Are Technical Debt
When base URL is hardcoded in Constants.swift or BuildConfig, every environment switch requires code changes and rebuild. CI builds three different artifacts. A tester waits for a new build to test the same thing on staging. This doesn't scale.
Correct Architecture
Level 1: Build-time configuration. Different .xcconfig for iOS or buildConfigField for Android set the default environment for each configuration:
// build.gradle
buildTypes {
debug {
buildConfigField "String", "DEFAULT_ENV", "\"dev\""
buildConfigField "String", "API_URL_DEV", "\"https://api-dev.example.com\""
buildConfigField "String", "API_URL_STAGING", "\"https://api-staging.example.com\""
buildConfigField "String", "API_URL_PROD", "\"https://api.example.com\""
}
release {
buildConfigField "String", "DEFAULT_ENV", "\"prod\""
// staging and dev URLs not needed in release
}
}
Level 2: Runtime switching. For debug/beta builds — save the current environment in SharedPreferences/UserDefaults, read on each request:
enum Environment: String, CaseIterable {
case dev = "dev"
case staging = "staging"
case production = "production"
var baseURL: URL {
switch self {
case .dev: return URL(string: "https://api-dev.example.com")!
case .staging: return URL(string: "https://api-staging.example.com")!
case .production: return URL(string: "https://api.example.com")!
}
}
}
final class EnvironmentManager {
static let shared = EnvironmentManager()
var current: Environment {
get {
let raw = UserDefaults.standard.string(forKey: "app_environment")
?? Environment.dev.rawValue
return Environment(rawValue: raw) ?? .dev
}
set {
UserDefaults.standard.set(newValue.rawValue, forKey: "app_environment")
// signal network layer to restart
NotificationCenter.default.post(name: .environmentDidChange, object: nil)
}
}
}
Level 3: Network layer restart. After switching environments, you need to: log out the user (dev tokens don't work on prod), clear cache, recreate URLSession / OkHttpClient with new base URL. If the network layer is created as a singleton with cached base URL — this won't work without recreation. Correct architecture: NetworkClient takes Environment via DI container, recreates when environment changes.
What Changes with Environment
Environment is not just URL. Complete list of parameters that should switch:
- API base URL
- WebSocket URL (if any)
- Firebase project (analytics, Remote Config, Crashlytics — different projects for dev/prod)
- Feature flags defaults
- Push notification environment (APNs sandbox vs production)
- Analytics tracking ID
Firebase for different environments — via different GoogleService-Info.plist (iOS) or google-services.json (Android). File selection based on build flavor/configuration — standard practice.
Environment Switcher in UI
Placed in Debug Menu (hidden from user) or in Settings for TestFlight/Beta builds:
Environment
● Development https://api-dev.example.com
○ Staging https://api-staging.example.com
○ Production https://api.example.com
[Switch] ← logs out and applies new environment
After switching — alert warning about logout and need to restart. Can be done via exit(0) — controversial but widespread in dev builds.
Protection Against Accidental Production Use
In release builds, all Environment Switcher code should be absent: conditional compilation #if DEBUG / debug build flavor. In production app there's no point having staging or dev server URLs in the binary — this information shouldn't be exposed via reverse engineering.
Timeline — 1–3 days. Simple switcher with two environments — 1 day. Full integration with different Firebase projects, APNs environments, DI network layer rebuild — up to 3 days.