Live Activitiesを実装してみて分かったこと

AdMobでの広告導入が落ち着いたところで、アプリ内で進行中の作業（タイマーやタスクの進捗）をロック画面やDynamic Islandに表示できる「Live Activities」という機能を試してみることにしました。

1. ウィジェットの延長線上だと思っていたら別物だった

以前実装したウィジェットと同じWidgetKitの枠組みで作れると知り、似たようなものだろうと軽く考えていました。

ウィジェット: ホーム画面に置かれ、一定間隔で更新される
Live Activities: 進行中の一時的な状態を、ロック画面やDynamic Islandに表示する

実際に触ってみると、Live Activitiesは「今まさに進行中のイベント」を表現するための仕組みで、常に置かれているウィジェットとは目的も表示場所も異なると分かりました。似た技術基盤を使っていても、設計の考え方から見直す必要がありました。

実装を進める中で、Live Activitiesには明確な「開始」「更新」「終了」というライフサイクルがあり、それぞれをコードで管理する必要があると知りました。

let activity = try Activity<MyAttributes>.request(
    attributes: attributes,
    contentState: initialState
)

「表示したら終わり」ではなく、進捗が変わるたびに更新処理を呼び出し、作業が完了したら明示的に終了処理を呼び出す必要がありました。始めたら終わらせるところまで責任を持って実装する必要がある、という当たり前のようで見落としがちな点に気づかされました。

進捗をリアルタイムで細かく更新しようとしたところ、想定より更新が反映されないことがありました。

調べてみると、Live Activitiesの更新にはシステム側の頻度制限があり、あまりに短い間隔で更新をリクエストしても、すべてが即座に反映されるわけではないと分かりました。バッテリー消費を抑えるための仕組みだと理解してからは、更新の粒度を「必要な変化があったときだけ」に絞る設計に変更しました。

シミュレーターでも一応の動作確認はできたのですが、実際のDynamic Islandでの見た目（コンパクト表示・展開表示それぞれの見え方）は、対応した実機で確認しないと正確には分からないと実感しました。

プッシュ通知やCloudKitのときと同様、OSの実際の挙動に関わる機能はシミュレーターだけで完結させず、実機確認を計画に組み込んでおくことが重要だと改めて学びました。

見た目の華やかさに惹かれて手を出しましたが、ライフサイクル管理や更新頻度の制約など、地味だが重要な設計判断が求められる機能だと実感しました。

本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。