LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Live Activities・Dynamic Islandとは

Live Activities・Dynamic Islandを使ったアプリ外注とは、iOSのロック画面やDynamic Island領域にリアルタイム情報を常駐表示する機能を、ActivityKitとWidgetKitの知識を持つ外部パートナーに実装委託する開発形態です。自社エンジニアにAppleフレームワーク固有のスキルが不足している場合や、既存アプリへの後付け追加を短期で完了させたい場合に、外注が選択肢として挙がります。

Live ActivitiesはAppleのActivityKit（iOS 16.1以降対応）で実装するリアルタイム情報表示機能で、ロック画面に配達状況・スポーツのスコア・乗換案内・通話状態などを継続表示できます。Dynamic IslandはiPhone 14 Pro以降のモデルで利用できる前面カメラ周辺の常駐表示領域で、Live Activitiesと連動して情報をコンパクトに見せます。

UIの定義にはWidgetKit（ウィジェット開発フレームワーク）を使い、アプリ本体とExtensionターゲットを組み合わせて構成します。既存アプリへの追加実装となるため、エンジニアにはActivityKit・WidgetKit両方の理解に加え、サーバ側のプッシュ基盤への知識も求められます。

実装の全体像：更新方式・領域設計・表示制約

アプリ直接更新とAPNs経由更新の違い

Live Activitiesの情報更新には2つの方式があります。1つ目はアプリがフォアグラウンドまたはバックグラウンドで直接Activity状態を更新する方式です。アプリが起動中はリアルタイム性が高い一方、アプリが非起動の間は更新できません。

2つ目はAPNs（Apple Push Notification service）経由で更新する方式です。サーバ側からActivityKitのPushトピックに向けてpayloadを送信することで、アプリが非起動でも情報を更新できます。iOS 17.2以降ではチャンネルを利用したブロードキャスト配信にも対応しています。外注の場合、このAPNs更新を実現するにはサーバ側のプッシュ基盤構築が必要となるため、バックエンド連携設計が見積りの重要な変数になります。

Dynamic Island 3領域の設計ポイント

Dynamic Islandの表示には3つの領域モードがあります。「compact leading / trailing」は他のアプリと共存して左右にコンテンツを表示するモード、「minimal」は他のLive Activityと同時表示される際の最小表示モード、「expanded」はタップ時に展開して詳細情報を見せるモードです。

それぞれのサイズ制約に合わせてUIを設計する必要があり、情報量の優先順位を整理した上でデザインを決めることが求められます。compact時に何を見せるか、expanded時にどこまで表示するかを事前に要件定義しておかないと、実装工程でのやり直しが発生しやすくなります。

表示時間と対応端末の制約

Live Activitiesには表示時間の制約があります。Appleの仕様によれば、ActivityはiOS側が最長約8時間で自動終了させる挙動があります。配達完了通知やレース終了など、イベントの終了をアプリまたはサーバから明示的にendActivityするよう設計しておくことが望ましいです。

Dynamic Islandが表示されるのはiPhone 14 Pro・iPhone 14 Pro Max以降のモデルに限定されます。それ以前のモデルではロック画面上のLive Activitiesのみ表示されます。外注時には、Dynamic Island非対応端末でも正常に動作するフォールバック設計を含めているか確認することが大切です。

外注で進める4ステップ：要件定義からリリースまで

ステップ1：表示内容と更新タイミングの要件定義

最初に「何をリアルタイム表示したいか」「どのタイミングで情報を更新するか」を言語化します。配達トラッキング・スポーツのライブスコア・タクシー到着時刻など、Live Activitiesが有効なユースケースは明確です。一方、静的な告知や更新頻度が低い情報にはLive Activitiesは適していません。

要件定義の段階でAPNs更新が必要かどうかも判断します。アプリ直接更新のみで要件を満たせるなら、サーバ側の追加開発コストを省けます。APNs経由が必要な場合は、既存のバックエンド（APIサーバ・通知基盤）との連携設計をこの段階で確認します。

ステップ2：ActivityKit Extension追加とサーバ連携設計

Xcodeプロジェクトに「Widget Extension」ターゲットを追加し、ActivityAttributesプロトコル（Activity状態を定義する構造体）を設計します。アプリ本体との情報受け渡しインターフェースを明確に決めることで、後工程での手戻りを減らせます。

APNs更新を採用する場合、サーバ側にはActivity Pushトークンの受け取り・管理・送信の仕組みが必要です。既存の通知基盤（FCM連携等）とは独立したAPNsのp8キー設定も求められます。バックエンドエンジニアとiOSエンジニアが分離している場合、この設計ミーティングを外注先と発注側の双方が揃って行うことが重要です。

ステップ3：WidgetKit UIの実装と端末別動作確認

WidgetKitのSwiftUI（宣言的UIフレームワーク）を用いてcompact / minimal / expandedそれぞれのViewを実装します。Dynamic Island非対応端末向けのロック画面レイアウトも別途設計します。各レイアウトでフォントサイズ・行数・情報密度が異なるため、デザイナーとの連携が欠かせません。

動作確認はシミュレータとiPhone 14 Pro以降の実機の両方で実施します。APNs更新の場合は実機でなければ本番同等の挙動を確認できないため、テスト端末の用意を事前に外注先と合意しておくことが大切です。

ステップ4：App Store審査対応と既存機能への影響確認

Live Activitiesを追加したバージョンはApp Store審査を通す必要があります。既存機能のバグが審査で指摘されるリスクもあるため、外注先には既存アプリのリグレッションテストも含めて依頼することが望ましいです。

Dynamic Island非対応端末・iOS 16.1未満端末でのフォールバック動作も審査前に確認します。バージョン分岐処理を誤ると古いOSのユーザーでクラッシュが発生するリスクがあります。外注先に「端末・OSバージョン別の動作マトリクス」の提出を求めることで、見落としを防げます。

費用を左右する要素と依頼前の確認ポイント

Live Activities実装の外注費用は、要件の複雑さによって大きく異なります。以下に費用変動の主な要素を整理します。

外注先への依頼前に確認しておくべき点を以下に挙げます。

• 既存アプリのiOSバージョン対応範囲（iOS 16.1未満はLive Activities非対応）
• APNsの証明書・p8キーの管理状況（Apple Developer Programの契約者が管理しているか）
• サーバ側のプッシュ通知基盤の有無と仕様（REST APIでpayloadを送れるか）
• デザイン担当の役割分担（Figmaデータを発注側が用意するか外注先に依頼するか）
• 既存アプリのソースコードを外注先に開示できるか、またはExtensionターゲットのみ分離して渡せるか

費用レンジは要件の複雑さで大きく変わります。市場参考値（一次資料ではありません）として、アプリ直接更新のみのシンプルな実装であれば数十万円台、APNs基盤の新設を含む場合は百万円を超える規模になる事例があります。正確な費用は複数社に要件を説明した上でRFP（提案依頼書）ベースで見積りを取ることをお勧めします。

ActivityKit実績とバックエンド連携経験で選ぶ外注先

Live Activities実装は比較的新しい機能であるため、外注先の実績確認が特に重要です。以下の観点で評価することが大切です。

ActivityKit・WidgetKit両方の実装実績

Live ActivitiesはActivityKitとWidgetKitを組み合わせて実装します。ウィジェット（静的表示）のみの経験ではActivityKit特有の状態管理・更新ライフサイクルに対応できないことがあります。Live Activitiesを実際に本番リリースした案件の有無を確認します。

APNsプッシュ基盤の構築・連携経験

APNs経由の更新が必要な場合、iOSクライアント実装だけでなくサーバ側のpayload設計・トークン管理・送信基盤の構築まで対応できるかを確認します。iOSエンジニアとバックエンドエンジニアを社内で兼務または協力できる体制かどうかが、進行のスムーズさに直結します。

既存アプリへの後付け実装の経験

新規アプリの場合と異なり、既存アプリへの追加実装には既存コードへの影響調査・テスト工数が加わります。Extensionターゲットの追加がビルド設定・証明書管理に影響する場合もあり、経験の浅い会社では予期しない問題が発生しやすい傾向があります。「既存アプリへのLive Activities後付け実装」の経験を具体的に確認することが大切です。

バッテリー・通信量への配慮設計

Appleは更新頻度について「ユーザーエクスペリエンスを損なわないよう適切な頻度に抑えること」を開発者向けドキュメントで案内しています。頻繁すぎる更新はバッテリー消費・通信量の増加につながり、ユーザーからのアンインストールリスクが上がります。外注先が更新頻度設計の観点を持っているかを確認することが重要です。

まとめ：外注判断の3つの軸

本稿ではLive Activities・Dynamic Islandの外注実装について、機能の概要から外注ステップ・費用変動要素・外注先選定まで整理しました。要点を3つに集約すると次のとおりです。

第一に、APNs経由更新の要否がコストと体制を左右します。アプリ直接更新で要件を満たせる場合はサーバ開発コストを抑えられますが、リアルタイム性が必要なユースケースではAPNs基盤の新設が不可欠です。第二に、Dynamic Island対応は端末限定の機能であり、非対応端末へのフォールバック設計を外注スコープに明示することが後戻り防止につながります。

第三に、外注先の選定ではActivityKit実装実績とバックエンド連携経験を両軸で確認します。Live ActivitiesはiOSクライアントとサーバ側プッシュ基盤が連携して初めて機能するため、片方のみ得意な会社に依頼すると工程途中で責任の境界が曖昧になるリスクがあります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Apple「ActivityKit — Apple Developer Documentation」（https://developer.apple.com/documentation/activitykit）
2. *2　出典：Apple「Displaying live data with Live Activities — Apple Developer Documentation」（https://developer.apple.com/documentation/activitykit/displaying-live-data-with-live-activities）

Tweet