はじめに

iOSアプリ開発において、ヘビーな処理（動画の骨格解析など）を実行中にユーザーがアプリを閉じてしまう「バックグラウンド移行」への対応は、避けては通れない難所です。

今回、アドベントカレンダーの記事として、最新のiOS環境（iOS26 / iPhone 16等）でのバックグラウンド動作制限について徹底的に調査しました。自分自身のメモとして残します。

この画像はAIによる生成です。

※この記事での「バックグラウンド」の定義は、こちらの記事に基づき、アプリが背面へ回った状態を指します。

なぜバックグラウンド処理が必要なのか？

そもそも、なぜ多くの開発者がiOSのバックグラウンド制限に頭を悩ませるのでしょうか。
骨格解析という少し特殊なケースに限らず、一般的なアプリ開発においてもバックグラウンドでの継続処理が求められる場面は多く存在します。

この画像はAIによる生成です。

1. ユーザーを「待機画面」で縛りたくない

大容量データのダウンロード、動画の書き出し（エンコード）、複雑な画像編集の保存などは時間がかかります。ユーザーがその間ずっとアプリを開いたまま（フォアグラウンド）で待ってくれるとは限りません。「待ち時間にLINEを返したい」とアプリを閉じた瞬間に、それまでの進捗が消えてしまうのは、ユーザーにとって大きなストレスになります。

2. 即時性の高いデータの同期

ヘルスケアデータの取り込み、写真アプリのバックアップ、クラウドとの差分同期など、「次にアプリを開いたときには、すでに最新の状態になっていてほしい」というニーズは非常に一般的です。

3. 計算リソースを食うヘビーな処理（今回のケース）

今回私が取り組んでいる「動画の骨格解析」もこの一つです。Mediapipe【骨格解析SDK】を使って動画の全フレームを解析する場合、CPU/GPUに高い負荷がかかり、数十秒〜数分の時間を要します。

今回の課題の要約
本記事では「骨格解析」を具体例として扱っていますが、本質的には「OSにキルされずに、いかに数分間の重い処理を完結させ、UX（ユーザー体験）を維持するか」という、多くの開発者が直面する課題についての調査記録です。

結論：現状のままだと「長尺動画」は厳しい

結論から言うと、特別なバックグラウンド実装を行っていない現状では、数秒〜数十秒かかる処理を完結させるのは困難です。

20秒程度の動画（解析5〜10秒程度）: iPhone 16のような最新端末なら、バックグラウンド移行直後の「猶予時間」でギリギリ完了できる可能性があります。
1分以上の動画（解析30〜40秒以上）: ほぼ確実に処理が中断されます。

処理フローと時間の目安

この画像はAIによる生成です。

実機（iPhone 16）での検証結果は以下の通りです。

処理内容	所要時間（目安）	懸念点
骨格解析 (20秒動画)	約10秒	移行タイミング次第で完結可能
骨格解析 (1分〜動画)	30秒〜40秒以上	ここが最大のボトルネック
JSONアップロード	未計測	通信環境に依存する
APIリクエスト	数秒	比較的成功しやすい

iOSバックグラウンド処理の「2つの武器」とその限界

バックグラウンドでも処理を継続させるための正攻法は2つありますが、それぞれに高い壁があります。

この画像はAIによる生成です。

1. `beginBackgroundTask` (Expiration Handler)

アプリがバックグラウンドに回った直後、OSに処理の継続を「お願い」する方法です。

実行時間：最大約30秒
- ※iOS 12までは180秒ありましたが、iOS 13以降は30秒制限に厳格化されました。
メリット： 実装が比較的容易で、短時間の保存やAPI送信に適している。
デメリット： 30秒を超える解析処理は強制終了されます。

2. `BGTaskScheduler` (BGProcessingTask)

OSが最適なタイミングを見計らって処理を実行する仕組みです。

実行時間：最大約30分
実行タイミング：OSが決定（不確定）
- バッテリー残量、ネットワーク、ユーザーの行動パターンを学習して実行されるため、数分〜数時間後になることもザラです。
メリット： 長時間の処理が可能。
デメリット： 「今すぐ結果が欲しい」というリアルタイムなニーズには全く向きません。

🚨 避けられない「強制終了」のケース

どれだけ実装を工夫しても、以下の場合は処理が完全に遮断されます。

この画像はAIによる生成です。

アプリのタスクキル: ユーザーがマルチタスク画面からアプリを上にスワイプして終了させた場合、OSはすべてのプロセスを即座に停止します。
OSによるリソース回収: メモリ負荷が高い場合、バックグラウンドにいるアプリは優先的にキルされます。

突破口はあるのか？〜進捗の「保存と復元」〜

調査の過程で、単にバックグラウンドで動かし続けるのではなく、アプリの状態変化に合わせて処理をコントロールするアプローチが見えてきました。

iOS 18以降の BGContinuedProcessingTask の検討
- 最新APIにおけるバックグラウンド猶予時間の挙動変化をキャッチアップし、次世代のOSに備える。→補償OSがまだ最低OS16にしてるので現状厳しい。未来のお話
フォアグラウンド ↔ バックグラウンド間の進捗引き継ぎ実装
- 中断のハンドリング: willResignActive や didEnterBackground を検知したタイミングで、解析中のフレームインデックスや一時データをローカル（UserDefaultsやFile Manager）に即座に保存する。
- 再開のロジック: ユーザーが再びアプリを開いた（didBecomeActive）際に、保存されたインデックスから解析をリスタートさせる「レジューム機能」を構築する。
- UXの工夫: ユーザーには「中断されました。アプリを開くと再開します」といった通知や表示を出し、期待値を調整する。
「正攻法（BGTaskScheduler）」をあえて外す選択
- Appleのレビューガイドラインを遵守しつつ、不確定なOSのスケジュールに頼らずに、いかにユーザー体験を損なわずに処理を完結させるか。

（参考：iOSDC Japan 2025 プロポーザル - iOSアプリのバックグラウンド制限を突破して...）

まとめ

Androidと同様、iOSでもバッテリー寿命とシステムパフォーマンス維持のため、バックグラウンド処理は年々厳しく制限されています。

今回のスケジュール内で「完璧で安定したバックグラウンド解析」を実装するのは難易度が非常に高いことが分かりました。まずは「アプリを開いたまま待ってもらうUX」を磨きつつ、技術的には30秒以内の処理を確実に完結させる構成を検討するのが現実解と言えそうです。

同じ悩みを持つエンジニアの皆さんの参考になれば幸いです！

会社情報

bravesoftではiOS/Androidモバイルアプリの開発を行っています！
アプリ開発に興味がある方は是非是非、採用ページをご確認ください👀