iOSアプリのライフサイクルと状態遷移

「バックグラウンドで動いている」の実態を分解する

iOSアプリを閉じてもホーム画面のアイコンからすぐ元の画面に戻れる——この体験の裏側には、単純な「起動中／終了」の二値ではなく、5段階の状態機械が存在します。OSはメモリと電力を守るため、ユーザーの目に触れない場所でアプリを段階的に凍結し、必要なら通知すらせずに終了させます。この設計を正確に理解しないと、「バックグラウンドで処理が止まる」「データが消える」といった不具合の原因を切り分けられません。ここでは各状態の定義、遷移を引き起こすイベント、そして状態保存・復元の内部動作を見ていきます。

5つの状態とその定義

iOSアプリのライフサイクルはUIApplication.Stateとして公開される値を軸に、実際には次の5段階で管理されます。

ここで押さえるべきはBackgroundとSuspendedの違いです。Backgroundは「まだコードを実行できる」状態で、SuspendedはOSがプロセスをメモリスナップショットとして保持するだけの凍結状態です。Suspended中のアプリはタイマーもネットワーク通信も一切進行しません。

遷移を引き起こすイベントとコールバック

各遷移ではUIApplicationDelegate（SwiftUIではScenePhase）のメソッドが呼ばれ、アプリはここで保存・停止・再開の処理を行います。

重要なのは最後の行です。SuspendedからNot Runningへの遷移は、アプリ側に何のコールバックも呼ばれず起こります。凍結中のプロセスはコードを実行していないため、終了を知らせようがないのです。したがって「終了時に必ず後始末をしたい処理」は、終了イベントを待つのではなく、Backgroundへ入るapplicationDidEnterBackgroundの時点までに完了させておく必要があります。

Background実行の時間制限

Inactiveを経てBackgroundへ入った直後、アプリは無制限に走り続けられるわけではありません。OSはbeginBackgroundTask(expirationHandler:)で確保する猶予期間を与え、これを使い切ると強制的にSuspendedへ落とします。

var bgTask: UIBackgroundTaskIdentifier = .invalid

func applicationDidEnterBackground(_ application: UIApplication) {
    bgTask = application.beginBackgroundTask(withName: "finishUpload") {
        // 猶予期限が来た場合の後始末。ここで必ずendBackgroundTaskを呼ぶ
        application.endBackgroundTask(self.bgTask)
        self.bgTask = .invalid
    }

    DispatchQueue.global().async {
        self.uploadRemainingData()
        application.endBackgroundTask(self.bgTask) // 完了したら早めに解放
        self.bgTask = .invalid
    }
}

猶予期間を使い切ってendBackgroundTaskを呼ばないままだと、OSはアプリを強制終了させます。これは通常の状態遷移ではなくペナルティであり、次回起動時にOSがクラッシュ扱いで記録することもあります。位置情報の継続取得やVoIP着信待受などの特定用途では、Info.plistにバックグラウンドモードを宣言することで、この時間制限を実質的に免除される仕組みが用意されていますが、これは例外的な許可であり原則ではありません。

メモリ逼迫時の強制終了と再起動

Suspended状態のプロセスはCPUを使いませんが、メモリは占有し続けます。端末のメモリが逼迫すると、OSはSuspended中のプロセスをメモリ解放の対象として選び、通知なしに終了させます。優先順位はおおむね「フォアグラウンドで動いているアプリ」を最後まで残し、Suspendedのアプリのうち最も長く使われていないものから終了させる方式です。

この終了はNot Runningへの遷移であり、ユーザーがアプリスイッチャーでアイコンを見ている限り、次にタップしたときはOSが新規プロセスとして再起動し、あたかも継続していたかのようにUIを復元します。ユーザーからはSuspendedと強制終了後の再起動の区別がつきません。この体験を成立させているのがState Restoration（状態保存・復元）です。

状態保存・復元の内部動作

State Restorationは大きく2段階で構成されます。

UIKitはrestorationIdentifierが設定されたビューコントローラだけを保存対象とし、識別子のないビューは復元対象から外れます。復元時はまずストーリーボードやコード上の初期化でビュー階層を再生成し、そのうえで保存済みのスナップショットを流し込む2段構えです。これにより、単なる「最後の画面のスクリーンショットを見せる」演出ではなく、スクロール位置やテキスト入力途中の内容まで復元できる設計になっています。SwiftUIでは@SceneStorageがこの仕組みを簡潔なプロパティラッパーとして提供し、内部的には同じUIKitの復元経路に接続されています。

まとめ

iOSアプリはNot Running・Inactive・Active・Background・Suspendedの5状態を、着信やホーム画面遷移などのイベントに応じて移動し、各遷移でデリゲートメソッドが呼ばれます。BackgroundはOSが与える時間制限つきの実行猶予であるのに対し、Suspendedはメモリのみ保持しCPUを一切使わない凍結状態という明確な違いがあります。Suspended中のプロセスはメモリ逼迫時に通知なく終了させられますが、これは正常なライフサイクル管理であり、State Restorationの仕組みによって次回起動時にビュー階層とアプリ固有の状態を復元することで、ユーザー体験としては継続しているかのように見せています。この設計を前提にすると、永続化処理はSuspendedへの遷移を待たず、Background移行時点までに完了させておくべきだと分かります。より低いレイヤーのプロセス管理やメモリ回収の考え方は /os/ の話題とも重なります。