Runtime architecture flows describe how the application behaves across the full lifecycle: from cold start through user interaction to backgrounding, process death, and restoration. Understanding and correctly implementing these flows is what separates apps that "just work" from apps that lose user data, consume unexpected battery, produce ANRs, or crash on rotation.
| 1 | Overview | 2 | Android Lifecycle Flows |
| 3 | iOS Lifecycle Flows | 4 | Background Execution |
| 5 | Anti-Patterns to Avoid | 6 | References |
The platform lifecycle is the contract between the operating system and the application. The OS calls lifecycle methods according to resource pressure, user navigation, and system events. Applications that honour this contract are well-behaved — they save state before suspension, release resources when backgrounded, and restore state correctly when resumed. Applications that ignore the contract produce data loss, crashes, and excessive battery drain.
The Android Activity lifecycle has seven states: Created, Started, Resumed (visible and interactive), Paused (partially obscured), Stopped (fully obscured), Destroyed. Configuration changes (rotation, language, dark mode toggle) destroy and recreate the Activity — the most common source of state loss bugs. ViewModel survives configuration changes through ViewModelStore — this is the primary reason ViewModel exists. SavedStateHandle (backed by onSaveInstanceState) survives process death — use it for navigation arguments and form state that must survive even process termination.
Android may kill background processes to reclaim memory. There is no lifecycle callback for process death — the process is simply terminated. State that must survive process death: commit to Room database or DataStore before the app leaves the foreground. onStop() is the reliable final lifecycle event before potential process death. Do not rely on onDestroy() — it is not guaranteed to be called before process termination.
Coroutines launched without lifecycle awareness continue after the Activity is destroyed — leaking resources and potentially crashing on dead UI references. viewModelScope cancels all coroutines when the ViewModel is cleared (Activity destroyed non-temporarily). lifecycleScope.launchWhenStarted cancels collection when the lifecycle moves below Started — correct for UI-bound coroutines. repeatOnLifecycle(Lifecycle.State.STARTED) is the preferred API for collecting from Flows in the View layer.
iOS application states: Not Running, Active (foreground, receiving events), Inactive (foreground, not receiving events — during interruptions like calls), Background (executing code, limited time), Suspended (no code execution). The transition from Active to Background triggers applicationDidEnterBackground — the last reliable point to commit state before potential termination. iOS gives approximately 5 seconds of background execution time after this event.
Modern iOS (iOS 13+) uses scene-based lifecycle for multi-window support on iPad and Catalyst. UIWindowSceneDelegate receives scene-specific lifecycle events alongside the app-level UIApplicationDelegate. SwiftUI's @Environment(\.scenePhase) provides a reactive scene phase value (active, inactive, background).
iOS sends memory warnings (applicationDidReceiveMemoryWarning, didReceiveMemoryWarning on UIViewController) when the system is low on memory. Respond by releasing caches and non-critical resources. Applications that ignore memory warnings are terminated first when the system needs memory.
Android background execution is managed by WorkManager — the only reliable mechanism for guaranteed background work that survives process death and device restart. WorkManager uses JobScheduler (API 21+) or AlarmManager (API < 21) under the hood, selecting the appropriate mechanism automatically. Constraints: NetworkType.CONNECTED, requiresBatteryNotLow(), requiresCharging(). Expedited work: setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) for time-sensitive operations.
iOS background execution: BGProcessingTask for longer operations (up to 30 minutes when charging and on Wi-Fi). BGAppRefreshTask for lightweight data refresh (up to 30 seconds, system-scheduled). Register tasks in Info.plist with permitted identifiers. The system assigns execution time based on device state, battery level, and user patterns — do not assume immediate execution.
Activity stores list of transactions in a local variable. User rotates device. Activity is destroyed and recreated. Variable is empty. User sees an empty screen.
ViewModel stores the list. ViewModel survives rotation. The recreated Activity resubscribes to ViewModel's StateFlow and receives the existing data immediately.
Android Service that runs continuously in the background, consuming CPU and battery. Killed by Doze mode and background execution limits.
WorkManager with appropriate constraints. The work is guaranteed to execute when constraints are met — not necessarily immediately, but reliably.