[iOS/SwiftUI] Life Cycle

SwiftUI는 선언적 UI 프레임워크로, 뷰 자체가 State에 반응하여 UI를 갱신한다. UIKit과는 달리 ViewController가 없고, State를 중심으로 UI가 업데이트 되기 때문에 명시적 LifeCycle Method가 존재하지 않는다. 때문에 LifeCycle hook 대신 ‘Modifier’를 제공하는데 이마저도 UIKit처럼 상세하게 나뉘지는 않고 onAppear, onDisappear로 종류가 한정적이다.

State가 변하면 이를 감지해 View 전체를 re-render하게 되는데, 이때 메모리에서 View는 값 타입으로 변경점이 있는 부분만 재구성된다. 비동기 작업 역시 UIKit은 callback, delegate, notification 등을 활용하지만 SwiftUI는 Combine, async/await과 자연스러운 연계가 가능하다.

SwiftUI Life Cycle 상세 흐름

1. 앱 실행 → @main App Struct의 body 내 Scene 구성이 실행
2. 뷰가 화면에 표시될 때 onAppear modifier 실행
3. 상태 변화가 감지되면 뷰 전체가 다시 계산되고 화면 갱신
4. 뷰가 사라질 때 onDisappear 실행

비동기 이벤트 관리

SwiftUI는 State 변화를 중심으로 UI를 설계하기 때문에 비동기 작업 결과를 State에 반영하면 곧바로 화면에 반영할 수 있다.

Combine

특히 Combine의 Publisher - Subscriber 모델을 이용해 비동기 스트림을 처리하고, 이를 쉽게 UI 상태에 연결할 수 있다.

import SwiftUI
import Combine

class ViewModel: ObservableObject {
    @Published var text = "Loading..."
    private var cancellables = Set<AnyCancellable>()
    
    func loadData() {
        fetchDataPublisher()
            .receive(on: DispatchQueue.main)
            .sink { completion in
                if case .failure(let error) = completion {
                    self.text = "Error: \\(error.localizedDescription)"
                }
            } receiveValue: { value in
                self.text = value
            }
            .store(in: &cancellables)
    }
    
    func fetchDataPublisher() -> AnyPublisher<String, Error> {
        Just("Hello from Combine!")
            .delay(for: .seconds(2), scheduler: DispatchQueue.global())
            .setFailureType(to: Error.self)
            .eraseToAnyPublisher()
    }
}

struct CombineView: View {
    @StateObject private var vm = ViewModel()
    
    var body: some View {
        Text(vm.text)
            .onAppear {
                vm.loadData()
            }
    }
}

async / await

또한 SwiftUI는 async-await 문법을 직접 View에서 task modifier와 함께 사용할 수 있어, 비동기 코드를 깔끔하고 간결하게 작성할 수 있다. UIKit에서는 비동기 작업 이후 UI 업데이트를 위해 이벤트를 별도로 보내는 등의 관리가 필요하지만 SwiftUI는 상태 바인딩만 하면 된다.

import SwiftUI

struct AsyncView: View {
    @State private var text: String = "Loading..."
    
    var body: some View {
        Text(text)
            .task {
                await loadData()
            }
    }
    
    func loadData() async {
        do {
            let result = try await fetchData()
            text = result  // 상태 변경 → UI 자동 갱신
        } catch {
            text = "Error: \\(error.localizedDescription)"
        }
    }
    
    func fetchData() async throws -> String {
        try await Task.sleep(nanoseconds: 2 * 1_000_000_000)  // 2초 지연
        return "Hello from async/await!"
    }
}

불명확성

다만 SwiftUI는 명시적 LifeCycle을 사용하지 않기에 rendering이 씹혀 화면이 갱신되지 않거나, UI 업데이트가 되지 않는 문제가 발생하기도 한다. 이는 SwiftUI에서 State에 따라 View를 자동으로 그려주기에, 내부적으로 언제 뷰가 다시 re-render 되는지, 어떤 시점에 View의 LifeCycle 이벤트가 호출되는지 개발자가 예측하여 직접 제어하기 어렵기 때문이다. 즉, UIKit과는 달리 SwiftUI는 View의 LifeCycle 관리가 간접적이고 추상화되어 있다.

대표적인 문제들은 아래와 같다.

1. State 변경 감지 실패

SwiftUI는 @State, @StateObject 등의 State Property가 변경될 때만 뷰를 다시 그린다. (re-render) 때문에 상태가 변경되지 않거나, 상태가 변경되어도 SwiftUI가 이를 감지하지 못하면 랜더링 갱신이 일어나지 않는데 상태를 직접 변경하지 않고 내부 프로퍼티만 수정하거나, 참조 타입 내부 속성이 변했는데 @Published가 제대로 동작하지 않는 경우가 있다. 이때 모든 상태들이 State Property로 올바르게 관리되고 있는지에 대한 확인이 필요하다.

2. View의 Identity 충돌

SwiftUI는 View를 값 타입으로 처리하며, 내부적으로 View의 id나 데이터가 바뀌었는지 확인하여 이를 다시 그릴지 말지 결정한다. id가 없거나, 동일한 id가 재사용 될 때, SwiftUI가 View를 갱신하지 않고 그대로 재사용하는 경우가 있는데 List나 ForEach에서 고유한 id를 지정하지 않아 누락이 일어나는 경우가 많다. 이는 보통 id: \.self 나 고유한 식별자를 명시해주면 해결된다.

3. 비동기 작업과 View State 불일치

비동기 작업 중에 View가 사라졌다가 다시 나타나는 경우, 이전 작업 결과가 반영되지 않거나, 작업 완료 시점에 View가 이미 메모리에서 사라진 경우 UI 업데이트가 무시되는 현상이 생긴다. @State 변경 시 View의 유효성 확인이 필요하다.

4. View 재사용 & 메모리 최적화

SwiftUI는 성능 최적화를 위해 필요 없는 View는 메모리에서 해제하거나 다시 사용한다. 이때 onAppear, onDisappear modifier가 예상과 다르게 호출되는 경우가 있어 개발자가 직접 제어하기 어렵다. 이렇게 되면 View가 재생성되거나, 재사용되면서 예상하지 못하게 onAppear, onDisappear에 넣었던 로직이 여러번 호출되게 된다. 때문에 항상 상태를 추적해서 중복 호출을 방지해 주어야 한다.