URLSessionとCodableでのJSON通信が落ち着いたところで、次はアプリを閉じていても位置情報を記録し続けたいと考え、Core Locationのバックグラウンド位置情報取得に挑戦しました。
1. 通常の権限リクエストだけで十分だと思っていた
最初、アプリ起動中に使う位置情報と同じ感覚で、requestWhenInUseAuthorizationを呼べばバックグラウンドでも位置情報が取れるようになるものだと思い込んでいました。
locationManager.requestAlwaysAuthorization()実際にはバックグラウンドで位置情報を使い続けるには、まず「App使用中のみ許可」を取得した状態で一定期間動作させ、その後に「常に許可」への昇格をリクエストするという段階的な流れが推奨されており、いきなりrequestAlwaysAuthorizationを呼んでも意図した許可が得られないことがありました。
2. Info.plistの設定漏れで審査時に指摘されそうになった
権限リクエストのコードは書いたつもりだったのですが、動作確認中にアプリが位置情報の許可ダイアログを一切出さないという不具合に遭遇しました。
Info.plistに必要だった設定:
NSLocationAlwaysAndWhenInUseUsageDescription
NSLocationWhenInUseUsageDescription原因は、バックグラウンド用の利用目的説明文をInfo.plistに追加し忘れていたことでした。コード側の実装だけに気を取られ、Info.plistの設定漏れという初歩的なミスに気づくまで時間がかかりました。
3. バッテリー消費への配慮が抜けていた
動作確認のため精度優先の設定のまま長時間使い続けたところ、バッテリー消費が想定以上に激しいことに気づきました。
locationManager.desiredAccuracy = kCLLocationAccuracyBest常に最高精度で位置情報を取得し続ける必要がある場面はそれほど多くなく、desiredAccuracyを用途に応じて下げたり、distanceFilterで一定距離移動するまで更新を間引いたりする調整が必要でした。精度を上げれば上げるほど良いという思い込みが、バッテリー消費という別の問題を生んでいました。
4. シミュレータでは正しく検証できていなかった
シミュレータ上で位置情報のシミュレーション機能を使って動作確認をしていたのですが、実機でテストしたところバックグラウンドでの更新頻度や許可ダイアログの挙動がシミュレータと異なることが分かりました。
シミュレータとの違い:
バックグラウンドでの位置更新の間隔・タイミングが実機と異なる位置情報のバックグラウンド動作は実際の移動やOSの省電力制御が絡むため、シミュレータでの確認だけでは不十分だと痛感しました。以降は早い段階から実機を持って実際に歩いて確認する運用に変えました。
まとめ
- 「常に許可」はいきなりリクエストせず、「App使用中のみ許可」からの段階的な昇格フローで実装する
- Info.plistのバックグラウンド用利用目的説明文を忘れずに追加する
- 精度と更新頻度はバッテリー消費とのトレードオフを意識し、用途に応じて調整する
- バックグラウンド位置情報の挙動確認はシミュレータでは不十分。早い段階から実機で確認する
位置情報の取得自体は数行で書けても、権限まわりとバッテリー消費への配慮まで含めると想像以上に奥が深い実装でした。
次は、StoreKit 2でのサブスクリプション更新処理で分かったことをまとめます。
本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。
コメント