Lifecycle in Mobile Development: what it is, stages and how it works

App Lifecycle

Before diving into the lifecycle of individual screens, it's important to understand the lifecycle of the entire application as a whole. In iOS, the app goes through five states: Not Running, Inactive (in background, not receiving events), Active (active), Background (in background, code is executing) and Suspended (in background, code is paused). These states are managed in the AppDelegate through the methods applicationDidFinishLaunching, applicationDidBecomeActive, applicationWillResignActive, applicationDidEnterBackground and applicationWillTerminate.

In Android, the equivalent is the Application Lifecycle, tracked through the Application.ActivityLifecycleCallbacks interface. However, Android focuses more on the lifecycle of an Activity — an individual app screen. This is because an Android app can consist of multiple Activities, each with its own cycle.

The modern approach in Android is to use ProcessLifecycleOwner from the lifecycle-process library. It allows tracking the state of the entire process without being tied to a specific Activity. In iOS, UISceneDelegate (since iOS 13) or AppDelegate is used for tracking app state. SceneDelegate handles multiple windows (multiwindow) on iPad. Understanding the App Lifecycle is especially important for IT Sectr when developing apps with background synchronization, streaming, and VoIP calls.

Activity Lifecycle in Android

Activity is the basic component of an Android app, representing one screen. Activity has a clearly defined lifecycle managed by the operating system in response to user actions and system events (screen rotation, incoming call, low memory).

Important: onSaveInstanceState is called before onStop to save temporary state. Restoration occurs in onCreate via Bundle savedInstanceState or via SavedStateHandle in ViewModel. Without proper lifecycle handling, the app will lose all unsaved data on screen rotation.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putString("draft", draftText)
    }
    override fun onDestroy() {
        super.onDestroy()
        // Отписка от всех подписок
    }
}

Activity Lifecycle in Jetpack Compose

In Jetpack Compose, the Activity lifecycle remains unchanged, but Compose provides additional tools: Lifecycle-aware composition via LifecycleOwner, LifecycleEventEffect and DisposableEffect for automatic resource cleanup on destruction.

Fragment Lifecycle in Detail

Fragment in Android lives inside an Activity and has its own lifecycle, partially overlapping with Activity but adding new methods. Fragments can be added, replaced, removed without destroying the Activity, making them more flexible but also more complex.

Key Fragment Lifecycle methods: onAttach — Fragment attached to Activity (first call); onCreate — data initialization; onCreateView — View creation; onViewCreated — View created, UI can be configured; onStart — Fragment visible; onResume — Fragment in focus; onPause — Fragment loses focus; onStop — Fragment not visible; onDestroyView — View destroyed; onDestroy — Fragment destroyed; onDetach — Fragment detached from Activity.

Key difference from Activity: onCreateView and onDestroyView can be called multiple times (e.g., when switching TabLayout), while onCreate is called once. Accordingly, View initialization should be done in onViewCreated, not in onCreateView. Resources related to the View (e.g., RecyclerView adapters) should be cleaned up in onDestroyView.

ViewController Lifecycle in iOS

UIViewController is the base class for managing screens in iOS. Its lifecycle consists of a sequence of methods that UIKit calls automatically. Understanding this cycle is critical for proper UI initialization, data management, and memory handling.

Important: viewDidLoad is called only once in the lifetime of a View Controller. To update data on every appearance, use viewWillAppear. If you subscribe to NotificationCenter in viewWillAppear, be sure to unsubscribe in viewDidDisappear to avoid memory leaks.

SwiftUI Lifecycle

SwiftUI manages the lifecycle of Views through View structs. Instead of callback methods, SwiftUI uses onAppear and onDisappear modifiers. For global app states, the App Lifecycle is used via App and Scene protocols. SwiftUI automatically manages the creation and destruction of Views based on state, simplifying development but requiring an understanding of View identity and lifetime.

struct ContentView: View {
    var body: some View {
        Text("Hello")
            .onAppear {
                print("View появилась")
            }
            .onDisappear {
                print("View исчезла")
            }
    }
}

LifecycleOwner and LifecycleObserver in Android

LifecycleOwner is an interface from Android Architecture Components that marks an object having a lifecycle (Activity, Fragment). LifecycleObserver is an interface that allows an object to subscribe to LifecycleOwner events. Together they form the foundation of reactive lifecycle management in modern Android development.

Instead of explicitly calling methods in onStart/onStop, it is recommended to use DefaultLifecycleObserver (replacement for the deprecated LifecycleObserver with @OnLifecycleEvent annotations). This is the approach promoted by Google for ViewModel and other components that need to react to lifecycle events without having direct references to Activity or Fragment.

class MyObserver : DefaultLifecycleObserver {
    override fun onStart(owner: LifecycleOwner) {
        // Подписка на обновления
    }
    override fun onStop(owner: LifecycleOwner) {
        // Отписка
    }
}

At IT Sectr, we use LifecycleOwner in all Android projects. ViewModel subscribes to the Activity's LifecycleOwner via viewModelScope and lifecycleScope, guaranteeing automatic cancellation of coroutines when the Activity is destroyed. This prevents memory leaks and makes the code cleaner and safer.