⬡ 開発ツール/2026-06-15上級

Rork Max が生成した Swift アプリで Dynamic Island に進行状況を映す

Rork Max が出力した Swift アプリに ActivityKit の Live Activity を足し、Dynamic Island へ進行状況を表示するまでの実装手順と、本番で踏んだ更新まわりの落とし穴を整理しました。

Rork Max¹⁵⁵ Dynamic Island² ActivityKit² Live Activities² SwiftUI⁴⁸

✦ プレミアム記事

タイマー系の小さなアプリを App Store に出していたとき、レビュー欄に「アプリを閉じると残り時間が分からなくなる」という声が続けて届きました。ホーム画面に戻っても、ロック画面でも、残り時間を見たい。その願いに応えられる場所が Dynamic Island です。

Rork Max は Swift のネイティブコードを生成してくれますが、Live Activity のように「アプリの外側に状態を出す」仕組みは、生成された雛形をそのまま動かすだけでは足りません。Extension のターゲット追加、表示状態の作り分け、更新の予算管理といった泥臭い部分は、結局こちらで手を入れることになります。ここでは、私自身が個人開発のアプリへ組み込んだときの順番でまとめます。

Dynamic Island は Live Activity の「もう一つの出力先」

最初に誤解を解いておきます。Dynamic Island は単独の API ではありません。ActivityKit の Live Activity を定義すると、その同じ状態が「ロック画面のバナー」と「Dynamic Island」の両方に流れていきます。つまり一つの状態モデルを書けば、表示先が二つ付いてくるという構造です。

ここを理解しておくと、後の作り分けが「同じデータを違う見た目で描くだけ」という話に収まります。逆に言えば、状態モデルの設計を先に固めないと、二つの表示先で破綻します。

状態モデルを定義する

Live Activity の中心は ActivityAttributes です。変化しない属性（タイトルなど）と、刻々と変わる ContentState（残り時間など）を分けて定義します。

import ActivityKit
import SwiftUI
 
struct TimerAttributes: ActivityAttributes {
    public struct ContentState: Codable, Hashable {
        var endDate: Date
        var isPaused: Bool
    }
 
    var taskName: String
}

ContentState には「更新で書き換わる値」だけを入れます。taskName のように起動後に変わらないものは外側へ置きます。この線引きを最初に決めておくと、更新コードが薄く保てます。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦ActivityAttributes と ContentState を定義し、最小構成の Live Activity を3ステップで起動する手順

✦compact / minimal / expanded の3表示を作り分ける DynamicIsland ビルダーの実コード

✦8時間上限・更新予算・push 更新の APNs ヘッダなど、本番で詰まりやすい7つの注意点

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

最小構成の Live Activity を起動する

属性が決まったら、アプリ本体から Activity を開始します。ここは Rork Max が生成したビューモデル層から呼び出すのが自然です。

func startTimerActivity(name: String, minutes: Int) throws {
    guard ActivityAuthorizationInfo().areActivitiesEnabled else {
        throw ActivityError.notAuthorized
    }
 
    let attributes = TimerAttributes(taskName: name)
    let end = Date().addingTimeInterval(Double(minutes) * 60)
    let state = TimerAttributes.ContentState(endDate: end, isPaused: false)
 
    let activity = try Activity.request(
        attributes: attributes,
        content: .init(state: state, staleDate: end.addingTimeInterval(60)),
        pushType: nil
    )
    print("started activity: \(activity.id)")
}

staleDate を渡しておくと、終了時刻を過ぎた表示をシステムが「古い」と判断してくれます。私はここを終了の1分後にして、ぴったり0秒の瞬間に表示が消えない余白を持たせています。

Dynamic Island の3つの表示を作り分ける

ここが本題です。Widget Extension 側で ActivityConfiguration を書き、dynamicIsland クロージャの中で compact・minimal・expanded を埋めます。

struct TimerLiveActivity: Widget {
    var body: some WidgetConfiguration {
        ActivityConfiguration(for: TimerAttributes.self) { context in
            // ロック画面 / バナー
            LockScreenView(context: context)
                .padding()
        } dynamicIsland: { context in
            DynamicIsland {
                DynamicIslandExpandedRegion(.leading) {
                    Label(context.attributes.taskName, systemImage: "timer")
                }
                DynamicIslandExpandedRegion(.trailing) {
                    Text(timerInterval: Date()...context.state.endDate)
                        .monospacedDigit()
                        .frame(maxWidth: 64)
                }
            } compactLeading: {
                Image(systemName: "timer")
            } compactTrailing: {
                Text(timerInterval: Date()...context.state.endDate)
                    .monospacedDigit()
                    .frame(maxWidth: 44)
            } minimal: {
                Image(systemName: "timer")
            }
        }
    }
}

compactTrailing の幅を固定しているのは、桁数の変化でレイアウトが揺れるのを防ぐためです。monospacedDigit() と frame(maxWidth:) を併せて指定すると、59→60 のように桁が増えても島の幅が安定します。これは実機で確認しないと気づきにくい挙動でした。

Text(timerInterval:) を使うと、毎秒の更新をこちらから送らなくても、システム側がカウントダウン表示を進めてくれます。残り時間のような連続値はこの仕組みに任せるのが、更新予算の節約として効きます。

状態の更新とリモート更新の現実

一時停止や再開のように「節目で変わる状態」は、明示的に更新します。

func pause(_ activity: Activity<TimerAttributes>) async {
    var s = activity.content.state
    s.isPaused = true
    await activity.update(.init(state: s, staleDate: nil))
}

ローカル更新はこれで十分ですが、サーバ側のイベント（配達状況の変化など）を反映したい場合は push 更新になります。Activity.request の pushType: .token で受け取ったトークンを自前バックエンドへ送り、APNs に apns-push-type: liveactivity ヘッダ付きで投げます。ここを alert のままにすると無言で届かないので、最初に必ず確認すべき点です。

本番で踏んだ落とし穴

短いアプリでも、出してみて初めて分かる制約がいくつもありました。実際に詰まった順に挙げます。

Live Activity は開始から最長8時間で自動終了します。長時間タイマーは終了後の再開導線を別に用意する必要があります。
更新には頻度の予算があり、毎秒 update を呼ぶと途中から間引かれます。連続値は Text(timerInterval:) に任せ、明示更新は節目だけにします。
push 更新では apns-push-type を liveactivity にしないと届きません。alert のまま数時間溶かしました。
シミュレータでは Dynamic Island の挙動が実機と一致しません。表示確認は実機が前提です。
staleDate を設定し忘れると、終わった表示が居残ります。
終了は activity.end(...) で dismissalPolicy を指定します。即時消去なら .immediate、余韻を残すなら .after(date) です。
Info.plist に NSSupportsLiveActivities を YES で入れないと、そもそも起動しません。生成直後の plist には入っていないことが多いので、ここは手で足します。

数字で言えば、私の手元では明示更新を「節目だけ」に絞ったことで、1時間あたりの更新回数が体感で 1/10 ほどに減り、システムによる間引きの警告も消えました。

どこまで自分で書き、どこを任せるか

私の運用では、状態モデル（ActivityAttributes）と更新ロジックは自分で設計し、ロック画面ビューの初期レイアウトや色合わせのような部分を Rork Max に任せています。理由は単純で、状態設計を誤ると二つの表示先が同時に崩れ、後からの修正コストが高いからです。逆に見た目の調整は生成と手直しの往復が速く、AI に下書きさせる価値が大きい領域だと感じています。

Dynamic Island は「アプリを開いていない時間」に価値を届ける数少ない場所です。AdMob のような広告収益とは違い、ここは体験そのものの満足度に効きます。残り時間が島に出ているだけで、レビューの雰囲気が和らいだのを実際に見てきました。小さくても、最初の一つを通しておく価値は十分にあります。

実装の参考になれば幸いです。