iOS 멀티 씬 앱에서 화면이 백그라운드로 갈 때 무엇을 저장해야 하나요? 앱 종료 알림만 기다려도 될까요?

앱 종료 알림을 마지막 저장 기회로 삼으면 데이터 유실을 막을 수 없습니다. iOS 멀티 씬에서는 프로세스 전체 생명주기와 각 UIScene의 활성·비활성·백그라운드 전환을 분리하고, 다시 계산하기 어려운 상태를 값이 바뀌는 시점과 씬이 백그라운드로 들어가는 시점에 저장하겠습니다. 백그라운드 진입은 저장을 시작하라는 신호이지 무한히 실행할 시간이 생겼다는 보장이 아니며, 종료 콜백은 호출되지 않을 수 있는 보조 기회입니다.

씬 상태와 공용 상태의 소유자를 나눕니다

iOS 13 이후 UIKit 앱에서는 하나의 프로세스 안에 여러 UI 윈도우 세션이 존재할 수 있고 각 세션을 관리하는 단위가 scene입니다. 한 씬은 화면에 보이고 다른 씬은 백그라운드일 수 있으므로 선택된 문서, 편집 중인 텍스트, 화면 복원 정보, 씬별 진행 작업은 해당 씬의 상태로 둡니다. 계정·공유 문서처럼 여러 씬이 함께 보는 데이터는 앱 수준 저장소에 둘 수 있지만, 두 씬이 같은 값을 동시에 수정할 때 마지막 저장이 무조건 승리한다고 가정하지 않겠습니다. 변경 버전, 충돌 정책, 실패 후 재시도 소유자를 정해야 합니다. 이처럼 저장 단위를 실제 생명주기 소유자에 맞추는 것을 씬 단위 상태 관리(scene-scoped state management)라고 부릅니다.

사용자가 홈으로 이동하거나 다른 앱을 전면에 두면 씬은 활성에서 비활성·백그라운드로 이동할 수 있습니다. sceneDidEnterBackground 같은 지점에서는 결제 초안, 문서 편집 내용, 다시 계산할 수 없는 선택 상태를 먼저 원자적으로 저장합니다. 큰 파일을 직접 덮어쓰다가 중단되면 기존 복구본까지 손상될 수 있으므로 임시 파일에 완전히 기록하고 flush·검증한 다음 교체하는 방식을 사용하겠습니다. 네트워크 동기화나 정리 작업은 만료될 수 있으므로 작은 재개 단위와 진행 상태를 남기고, 다음 활성화 때 이어서 처리합니다.

종료보다 변경과 복구를 믿습니다

사용자가 앱을 스와이프해 종료하거나 시스템이 메모리 압박으로 프로세스를 종료하면 applicationWillTerminate와 유사한 마지막 콜백이 호출된다는 보장이 없습니다. 따라서 입력이 바뀔 때마다 저장하거나 짧은 debounce 뒤 원자적으로 기록하고, 백그라운드 진입 때 저장을 한 번 더 시도하겠습니다. 키체인은 인증 정보, 파일·데이터베이스는 복구해야 할 앱 상태처럼 목적에 맞게 나누고, 저장 형식에 버전을 넣어 새 코드가 이전 상태를 마이그레이션할 수 있게 합니다.

저장 완료를 기다리는 동안 백그라운드 시간이 끝날 수 있으므로, 가능한 범위에서 시스템의 background task 시간과 만료 콜백을 이용하되 그 시간이 보장된다고 간주하지 않습니다. 저장 실패를 성공으로 표시하지 말고 다음 실행에서 미완료 상태를 복구하거나 사용자에게 재시도할 수 있게 해야 합니다. SwiftUI를 함께 사용한다면 scenePhase와 SceneDelegate 콜백이 같은 저장을 중복 실행할 수 있으므로 저장 ID·버전·멱등 검사를 둡니다.

검증은 여러 씬을 열어 한쪽만 백그라운드로 보내고, 입력 변경 직후 강제 종료·메모리 종료·저장 중단을 주입하는 방식으로 합니다. 재실행 뒤 마지막 유효 스냅샷이 읽히는지, 임시 파일이 노출되지 않는지, 같은 문서를 수정한 두 씬의 충돌이 정책대로 보이는지를 확인하겠습니다. 핵심은 앱이 종료될 때 저장하는 것이 아니라 손실을 감당할 수 없는 상태를 더 이른 시점에, 소유자와 복구 규칙이 분명한 형태로 영속화하는 것입니다.