◇ アプリ開発/2026-07-01上級

Rork Max のネイティブ Swift で AlarmKit のタイマーを実装する — 消音・集中モードを越えて鳴らす

ローカル通知が消音モードや集中モードで鳴らない問題を、iOS 26 の AlarmKit で解決する実装メモです。認可・カウントダウンの schedule・ロック画面と Dynamic Island の Live Activity・実行中タイマーの一覧までの Swift コードと、Rork Max のネイティブ生成や Expo からの橋渡しの境界設計を、実際にハマった点を添えてまとめます。

AlarmKit Rork Max²⁰² Live Activity iOS⁹⁵ タイマー²

✦ プレミアム記事

個人開発で小さなインターバルタイマーを作っていたとき、テスターの一人から「マナーモードにしていると鳴らないんだけど」と言われました。手元の検証では問題なく動いていたので、最初は再現できずに戸惑いました。原因は単純で、私が UserNotifications でローカル通知を組んでいたからです。消音スイッチを入れた iPhone では、通知の音は鳴りません。タイマーやアラームのように「鳴らないと意味がない」種類の通知にとって、これは致命的でした。

長らく、この壁を越える正規の手段は Critical Alerts entitlement だけでした。けれどこれは医療・安全・公共安全といった用途を想定した特別な権限で、Apple への申請が必要で、個人開発の小さなタイマーアプリではまず通りません。iOS 26 で登場した AlarmKit は、この状況を変えました。タイマーとアラームに限ってですが、申請なしで消音モードと集中モードを越えてアラートを鳴らせるようになったのです。Rork Max がネイティブ Swift を生成するようになったことで、この AlarmKit を個人開発でも現実的に組み込めるようになりました。実際に組み込んで分かったことを、手順としてまとめます。

私自身、個人開発で運営している小さなユーティリティ系のアプリにタイマー機能を足したとき、「鳴らない」という一点だけで使われなくなってしまう経験をしました。タイマーは、約束どおり鳴ることがそのままリテンションに直結する機能です。AdMob で広告を載せている無料アプリでも、「ちゃんと鳴るから使い続ける」という信頼が、結局は継続利用と収益の土台になります。その意味で AlarmKit は、単なる新 API ではなく、個人開発の小さなアプリの体験を一段引き上げる道具だと感じています。

なぜローカル通知では鳴らないのか

まず、ここを正確に押さえておくと後の設計判断が楽になります。UserNotifications で送るローカル通知やプッシュ通知は、端末の消音スイッチと集中モードの設定に従います。つまり利用者が消音にしていれば音は鳴らず、集中モードで遮断していればバナーも抑制されます。これはユーザーを邪魔しないための正しい挙動で、ニュースやマーケティング通知ではむしろ歓迎されるものです。

問題は、タイマー・アラーム・リマインダーのように「鳴ること自体が機能」の通知です。料理の3分タイマー、ワークアウトのインターバル、昼寝の30分アラーム。これらは消音中だからこそ鳴ってほしい場面が多いのに、ローカル通知では沈黙してしまいます。次の表が、3つの選択肢の差を端的に表しています。

手段	消音・集中モードを越えるか	申請の要否	個人開発での現実性
UserNotifications（ローカル通知）	越えない（沈黙する）	不要	高いが、鳴らない問題が残る
Critical Alerts entitlement	越える	Apple への個別申請が必要	低い（用途が限定され、まず通らない）
AlarmKit（iOS 26+）	越える	不要（利用者の認可のみ）	高い（タイマー・アラーム用途に限る）

AlarmKit は万能ではありません。任意の通知を鳴らし放題にする仕組みではなく、あくまで「ユーザーが自分で仕掛けたタイマー・アラーム」という文脈に限定されています。逆に言えば、その文脈にぴたりとはまるアプリにとっては、これまでなかった正規ルートが開いたということです。

最小構成でも、組み立てる部品はいくつかに分かれます。全体像を先に番号で押さえておくと、後のコードが追いやすくなります。

Info.plist に利用目的を書き、AlarmManager で利用者の認可を取る
アラートと属性を組み立て、schedule(.timer(...)) でカウントダウンを開始する
Widget Extension に Live Activity を実装し、ロック画面と Dynamic Island に残り時間を出す
alarmUpdates を購読してアプリ内に実行中タイマーを一覧し、必要なら cancel(id:) で止める

認可を取る

AlarmKit のアラートは集中モード中でも音を立てて画面に出るため、利用者の明示的な許可が前提になります。手順は2つです。まず Info.plist に NSAlarmKitUsageDescription を追加し、なぜアラームを仕掛けるのかを一文で説明します。この文言は、初回の認可ダイアログに Apple 標準の説明と並べて表示されます。

次に、認可状態を確認し、未決定なら requestAuthorization() でシステムプロンプトを出します。AlarmManager.shared がその窓口です。

import SwiftUI
import AlarmKit
 
struct TimerStartButton: View {
    private let manager = AlarmManager.shared
 
    var body: some View {
        Button("タイマーを開始", systemImage: "timer") {
            Task {
                if await ensureAuthorized() {
                    await scheduleTimer()
                } else {
                    // 拒否時: 機能を無効化し、設定アプリへの導線を出す
                }
            }
        }
    }
 
    private func ensureAuthorized() async -> Bool {
        switch manager.authorizationState {
        case .notDetermined:
            do {
                let state = try await manager.requestAuthorization()
                return state == .authorized
            } catch {
                print("認可エラー: \(error)")
                return false
            }
        case .authorized:
            return true
        case .denied:
            return false
        @unknown default:
            return false
        }
    }
}

.notDetermined の分岐でだけプロンプトを出している点が要点です。すでに .denied の利用者に毎回プロンプトを投げてもシステムは何も表示しませんし、.authorized なら即座に処理へ進めます。拒否されたときに何をするかは、アプリの性格で決めます。タイマーが主機能なら設定アプリへ誘導し、補助機能なら静かにローカル通知へフォールバックする、といった分岐が現実的です。

✦

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

この記事の続きを読む

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

この記事で得られること

✦UserNotifications では消音・集中モードで鳴らない理由と、AlarmKit が Critical Alerts 権限なしでそれを越える仕組み、置き換えの判断基準が分かります

✦認可リクエストからカウントダウンの schedule、ロック画面と Dynamic Island の Live Activity 最小構成までの、動く Swift コード一式が手に入ります

✦Rork Max が生成するネイティブ Swift で AlarmKit を使う手順と、Expo / React Native からネイティブモジュールで橋渡しする際の境界設計が身につきます

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

✦

この記事を購入する

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

または

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

カウントダウンタイマーを schedule する

認可が取れたら、いよいよタイマーを仕掛けます。最小構成でも数個の部品を組み立てる必要があるので、順に見ていきます。

最初に、タイマー終了時に出るアラートを AlarmPresentation.Alert で定義します。title と停止ボタンが必須で、停止ボタンは AlarmButton で文言・色・SF Symbol を指定します。

let alert = AlarmPresentation.Alert(
    title: "完了しました",
    stopButton: AlarmButton(
        text: "停止",
        textColor: .white,
        systemImageName: "checkmark"
    )
)

このアラートは2つの大きさで表示されます。端末がロック解除中ならコンパクトなバナー、ロック画面なら大きめの表示です。コンパクト版で省略されないよう、title は短く保つのが安全です。

次に AlarmAttributes を作ります。presentation と tintColor が必須で、metadata は任意ですが、AlarmAttributes は Metadata をジェネリックに取るため、空でも AlarmMetadata に準拠した型を渡す必要があります。これを忘れると Generic parameter 'Metadata' could not be inferred というコンパイルエラーになります。Xcode 26 で作ったプロジェクトは型がデフォルトで MainActor 隔離されるため、この型は nonisolated を付けてプロトコル準拠を満たします。

nonisolated struct TimerData: AlarmMetadata {}
 
let attributes = AlarmAttributes<TimerData>(
    presentation: AlarmPresentation(alert: alert),
    tintColor: .accentColor
)

ここまで揃えば、AlarmManager の schedule() に id と設定を渡してタイマーを開始できます。

private func scheduleTimer() async {
    let alert = AlarmPresentation.Alert(
        title: "完了しました",
        stopButton: AlarmButton(
            text: "停止",
            textColor: .white,
            systemImageName: "checkmark"
        )
    )
 
    let attributes = AlarmAttributes<TimerData>(
        presentation: AlarmPresentation(alert: alert),
        tintColor: .accentColor
    )
 
    do {
        _ = try await manager.schedule(
            id: UUID(),
            configuration: .timer(
                duration: 180, // 3分
                attributes: attributes
            )
        )
    } catch {
        print("スケジュールエラー: \(error)")
    }
}

duration を 180 にすれば3分タイマーです。実際のアプリではこの値を画面の入力やコンテキストから決めることになります。id に渡した UUID は後でキャンセルに使うので、必要なら保持しておきます。

ロック画面と Dynamic Island に残り時間を出す

ここまでで「終了時に鳴る」ところまでは完成しましたが、走っている最中の残り時間はまだどこにも出ていません。カウントダウンを常時表示するには、Live Activity が必要です。AlarmKit のカウントダウンは Live Activity の実装を前提にしている、という点は最初に戸惑いやすいので強調しておきます。

プロジェクトに Widget Extension ターゲットを追加し、ウィジェット用の雛形コードは消して、Live Activity の定義だけを残します。ActivityConfiguration に先ほどの AlarmAttributes を渡すのがポイントです。

import WidgetKit
import SwiftUI
import AlarmKit
 
@main
struct CountdownBundle: WidgetBundle {
    var body: some Widget {
        CountdownLiveActivity()
    }
}
 
struct CountdownLiveActivity: Widget {
    var body: some WidgetConfiguration {
        ActivityConfiguration(for: AlarmAttributes<TimerData>.self) { context in
            CountdownText(state: context.state)
                .font(.largeTitle)
                .padding()
        } dynamicIsland: { context in
            DynamicIsland {
                DynamicIslandExpandedRegion(.bottom) {
                    CountdownText(state: context.state)
                        .font(.headline)
                }
            } compactLeading: {
                CountdownText(state: context.state)
            } compactTrailing: {
                Image(systemName: "timer")
            } minimal: {
                Image(systemName: "timer")
            }
        }
    }
}

残り時間の描画は、context が持つ AlarmPresentationState から取り出します。.countdown のときだけ fireDate が得られるので、Date.now ... fireDate の区間を Text(timerInterval:) に渡すと、毎秒自動で更新される表示になります。自前でタイマーを回す必要はありません。

struct CountdownText: View {
    let state: AlarmPresentationState
 
    var body: some View {
        if case let .countdown(countdown) = state.mode {
            Text(timerInterval: Date.now ... countdown.fireDate)
                .monospacedDigit()
                .lineLimit(1)
        }
    }
}

ひとつ落とし穴があります。TimerData の定義は、アプリ本体ターゲットと Widget Extension ターゲットの両方にコンパイルされる必要があります。専用の Swift ファイルに切り出し、ファイルの Target Membership を両ターゲットにチェックしておくのが一番確実です。これを忘れると、Live Activity 側で型が見つからずビルドが通りません。

アプリ内で実行中のタイマーを一覧する

タイマーを仕掛けてロック画面にも出せたら、次はアプリ前面で「いま動いているタイマー」を見せたくなります。AlarmKit は、システムがアラームを追加・削除・変更するたびに最新の一覧を流してくれる非同期シーケンス alarmUpdates を用意しています。これを購読すれば、ローカルの状態を同期し続けられます。

struct TimerListView: View {
    @State private var alarms: [Alarm] = []
 
    var body: some View {
        List(alarms) { alarm in
            TimerRow(alarm: alarm)
        }
        .task {
            for await updated in AlarmManager.shared.alarmUpdates {
                alarms.removeAll { local in
                    updated.allSatisfy { $0.id != local.id }
                }
                for alarm in updated {
                    if let i = alarms.firstIndex(where: { $0.id == alarm.id }) {
                        alarms[i] = alarm
                    } else {
                        alarms.insert(alarm, at: 0)
                    }
                }
            }
        }
    }
}

ここで知っておくべき制約があります。Alarm インスタンスが持つのは、識別子・最初に設定したカウントダウン時間・現在の状態（.countdown / .alerting / .paused）程度です。「いま残り何秒か」という生の値は持っていません。リアルタイムの残り時間は、Live Activity で使った AlarmPresentationState 経由でしか得られないのです。したがってアプリ内の一覧では、設定時間と状態ラベルを出すに留めます。識別子があるので、キャンセルボタンは作れます。

struct TimerRow: View {
    let alarm: Alarm
 
    var body: some View {
        HStack {
            switch alarm.state {
            case .countdown: Text("実行中")
            case .alerting: Text("鳴動中")
            case .paused: Text("一時停止")
            default: EmptyView()
            }
            Spacer()
            Button("キャンセル", systemImage: "xmark") {
                try? AlarmManager.shared.cancel(id: alarm.id)
            }
            .labelStyle(.iconOnly)
        }
    }
}

cancel(id:) で個別に止められます。この「生の残り時間はアプリ側に来ない」という設計は最初は不便に感じますが、カウントダウンの責務を Live Activity に一本化することで、アプリが前面にいなくても表示が破綻しないようになっている、と理解すると腑に落ちます。

Rork Max のネイティブ Swift と、Expo からの橋渡し

ここが、Rork を使う私たちにとっての本題です。AlarmKit は純粋なネイティブ iOS フレームワークで、Swift から呼ぶことが前提です。通常の Rork が生成する React Native（Expo）アプリからは、JavaScript の世界だけで AlarmKit に触れることはできません。一方、Rork Max はネイティブ Swift を生成するため、AlarmKit のような「React Native の標準では届かない」フレームワークを、生成コードの一部として組み込めます。

私の場合は、判断軸をこう置いています。アプリの中核がタイマー・アラームで、ロック画面の体験まで作り込みたいなら、最初から Rork Max のネイティブ Swift で組むことをお勧めします。一方、すでに Expo で大半を作っていて、一部の画面にだけ確実に鳴るタイマーが欲しい、という場合は、Expo Modules API でネイティブモジュールを切り出して橋渡しします。次の表が、その使い分けです。

状況	推奨アプローチ	橋渡しの境界
タイマー・アラームが中核機能	Rork Max のネイティブ Swift で実装	橋渡し不要。SwiftUI から直接 AlarmKit を呼ぶ
既存の Expo アプリに一部だけ追加	Expo Modules API でネイティブモジュール化	「開始・キャンセル・状態購読」だけを公開し、UI は JS 側
iOS 26 未満も同一バイナリで対応	availability で分岐し、旧 OS はローカル通知へ	モジュール内で `if #available(iOS 26, *)` 分岐

Expo Modules API で橋渡しする場合、JavaScript 側に公開するのは最小限に絞るのが肝心です。私は「タイマーを開始する」「id を指定してキャンセルする」「実行中の id 一覧を流す」の3つだけを境界にしました。AlarmPresentation や AlarmAttributes の組み立て、Live Activity の描画といった Swift 固有の部分は、すべてネイティブモジュールの内側に閉じ込めます。境界を薄く保つほど、後で AlarmKit 側の API が変わっても影響範囲が小さくて済みます。

// Expo Modules API で公開する最小の境界（イメージ）
import ExpoModulesCore
import AlarmKit
 
public class AlarmTimerModule: Module {
    public func definition() -> ModuleDefinition {
        Name("AlarmTimer")
 
        AsyncFunction("startTimer") { (seconds: Double) -> String in
            // 認可確認 → AlarmKit の schedule を呼び、id 文字列を返す
            let id = UUID()
            // ...（前述の schedule をここで実行）...
            return id.uuidString
        }
 
        AsyncFunction("cancelTimer") { (id: String) in
            if let uuid = UUID(uuidString: id) {
                try? AlarmManager.shared.cancel(id: uuid)
            }
        }
    }
}

注意したいのは、if #available(iOS 26, *) の分岐を必ず入れることです。Expo アプリは幅広い OS バージョンの端末に配られます。AlarmKit が使えない端末では、同じ「タイマー開始」の呼び出し口から、静かに UserNotifications のフォールバックへ切り替える設計にしておくと、JS 側のコードを OS バージョンで分岐させずに済みます。

実装で踏みやすい点

最後に、私が実際につまずいた箇所を、先回りして共有します。どれも一度知っていれば避けられるものばかりです。

AlarmMetadata 型を渡し忘れる: 空でも nonisolated struct TimerData: AlarmMetadata {} を用意して AlarmAttributes<TimerData> のように明示しないとコンパイルが通りません。
TimerData を両ターゲットに入れ忘れる: アプリ本体と Widget Extension の両方の Target Membership にチェックを入れます。片方だけだと Live Activity 側で型が解決できません。
title が長すぎて切れる: 終了アラートのコンパクト版は表示幅が狭いので、title は短く。
シミュレータでの過信: アラートの鳴動まわりは実機で確認するのが安全です。消音スイッチや集中モードの挙動は、実機でこそ意味があります。
拒否時のフォールバックを用意しない: .denied の利用者に対して機能が無言で死なないよう、設定への導線かローカル通知への切り替えを必ず用意します。

iOS 26 から使える機能なので、対応 OS の下限が iOS 26 を含まないアプリでは、availability 分岐とフォールバックの設計が実装の半分を占めます。逆に言えば、その分岐さえ丁寧に作れば、消音モードでも確実に鳴るタイマーという、これまで個人開発では難しかった体験を提供できます。まずは認可リクエストと3分タイマーの schedule までを、手元のプロジェクトで一度通してみてください。そこまで動けば、残りは表示の作り込みです。