Building an AlarmKit Timer in Rork Max's Native Swift — Alerts That Cut Through Silent Mode and Focus

Scheduling a countdown timer

Once authorized, you can schedule the timer. Even the minimal configuration assembles a few parts, so let's go through them in order.

First, describe the alert that appears when the timer ends with AlarmPresentation.Alert. It requires a title and a stop button; the stop button is an AlarmButton with text, color, and an SF Symbol.

let alert = AlarmPresentation.Alert(
    title: "Done",
    stopButton: AlarmButton(
        text: "Stop",
        textColor: .white,
        systemImageName: "checkmark"
    )
)

This alert appears at two sizes: a compact banner when the timer ends while the device is unlocked, and a larger one on the Lock Screen. Keep title short so it isn't truncated in the compact form.

Next, create AlarmAttributes. It requires a presentation and a tintColor. The metadata is optional, but AlarmAttributes is generic over Metadata, so you still have to supply a type conforming to AlarmMetadata even if it's empty. Forget it and you get the compile error Generic parameter 'Metadata' could not be inferred. In projects created with Xcode 26, where types are MainActor-isolated by default, mark this type nonisolated to satisfy the protocol.

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

With those in place, start the timer by passing an id and a configuration to AlarmManager's schedule().

private func scheduleTimer() async {
    let alert = AlarmPresentation.Alert(
        title: "Done",
        stopButton: AlarmButton(
            text: "Stop",
            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 minutes
                attributes: attributes
            )
        )
    } catch {
        print("Scheduling error: \(error)")
    }
}

Set duration to 180 for a three-minute timer. In a real app you'd derive that value from user input or context. Keep the UUID you pass as id if you want to cancel the timer later.

Showing remaining time on the Lock Screen and Dynamic Island

So far the timer rings when it ends, but the remaining time isn't displayed anywhere while it runs. To show a continuous countdown, you need a Live Activity. It's worth stressing early — AlarmKit's countdown assumes you implement a Live Activity, which catches a lot of people off guard.

Add a Widget Extension target, delete the boilerplate widget code, and keep only the Live Activity definition. The key is passing your AlarmAttributes to ActivityConfiguration.

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")
            }
        }
    }
}

Draw the remaining time from the AlarmPresentationState the context carries. Only in the .countdown case do you get a fireDate, so pass the Date.now ... fireDate range to Text(timerInterval:) for a view that updates every second on its own. No manual ticking required.

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)
        }
    }
}

One trap here: TimerData must compile into both the app target and the Widget Extension target. The safest move is to put it in a dedicated Swift file and check its Target Membership for both targets. Forget it and the Live Activity side can't resolve the type, and the build fails.

Listing active timers inside the app

Once timers schedule and surface on the Lock Screen, you'll want to show the ones "currently running" in the foreground app. AlarmKit provides an async sequence, alarmUpdates, that emits the full set of active alarms every time the system adds, removes, or mutates one. Subscribe to it to keep local state in sync.

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)
                    }
                }
            }
        }
    }
}

There's a constraint to know. An Alarm instance carries only a few things: its identifier, the countdown duration it was configured with, and its current state (.countdown / .alerting / .paused). It does not hold the live "seconds remaining" value — that only comes through the AlarmPresentationState you used in the Live Activity. So your in-app list can show the configured duration and a state label, nothing more. The identifier does let you cancel.

struct TimerRow: View {
    let alarm: Alarm
 
    var body: some View {
        HStack {
            switch alarm.state {
            case .countdown: Text("Running")
            case .alerting: Text("Alerting")
            case .paused: Text("Paused")
            default: EmptyView()
            }
            Spacer()
            Button("Cancel", systemImage: "xmark") {
                try? AlarmManager.shared.cancel(id: alarm.id)
            }
            .labelStyle(.iconOnly)
        }
    }
}

cancel(id:) stops a single one. This "the live remaining time never reaches the app" design feels inconvenient at first, but it makes sense once you see that consolidating the countdown's responsibility in the Live Activity is what keeps the display from breaking when the app isn't in the foreground.

Rork Max's native Swift, and bridging from Expo

This is the heart of it for those of us using Rork. AlarmKit is a pure native iOS framework meant to be called from Swift. From the React Native (Expo) apps that ordinary Rork generates, you can't touch AlarmKit from the JavaScript world alone. Rork Max, on the other hand, generates native Swift, so a framework like AlarmKit — one the React Native standard can't reach — can live inside the generated code.

My rule of thumb: if the core of the app is timers and alarms and you want to craft the Lock Screen experience, building in Rork Max's native Swift from the start is the natural path. If you've already built most of the app in Expo and only want a reliably-ringing timer on a few screens, carve out a native module with the Expo Modules API and bridge to it. The table shows the split.

When bridging via the Expo Modules API, expose as little as possible to JavaScript. I kept the boundary to just three things: "start a timer," "cancel by id," and "stream the active ids." All the Swift-specific parts — assembling AlarmPresentation and AlarmAttributes, drawing the Live Activity — stay sealed inside the native module. The thinner the boundary, the smaller the blast radius when AlarmKit's API later shifts.

// Minimal boundary exposed via the Expo Modules API (sketch)
import ExpoModulesCore
import AlarmKit
 
public class AlarmTimerModule: Module {
    public func definition() -> ModuleDefinition {
        Name("AlarmTimer")
 
        AsyncFunction("startTimer") { (seconds: Double) -> String in
            // check authorization → call AlarmKit's schedule, return the id string
            let id = UUID()
            // ...(run the schedule shown earlier here)...
            return id.uuidString
        }
 
        AsyncFunction("cancelTimer") { (id: String) in
            if let uuid = UUID(uuidString: id) {
                try? AlarmManager.shared.cancel(id: uuid)
            }
        }
    }
}

The thing to watch is always including the if #available(iOS 26, *) branch. Expo apps ship to devices across a wide range of OS versions. On devices where AlarmKit isn't available, design the same "start timer" entry point to quietly switch to a UserNotifications fallback, so your JS code doesn't have to branch on OS version itself.

Pitfalls you're likely to hit

Finally, the spots where I actually stumbled, shared ahead of time. Each is avoidable once you know it.

• Forgetting the AlarmMetadata type: even an empty nonisolated struct TimerData: AlarmMetadata {} must be declared and named explicitly, as in AlarmAttributes<TimerData>, or it won't compile.
• Forgetting TimerData in both targets: check its Target Membership for both the app and the Widget Extension. With only one, the Live Activity side can't resolve the type.
• A title that's too long and gets cut: the end-alert's compact form is narrow, so keep title short.
• Over-trusting the simulator: verify the ringing behavior on a real device. Silent switch and Focus behavior only mean something on hardware.
• No fallback on denial: make sure the feature doesn't die silently for .denied users — always provide a Settings path or a local-notification switch.

Since this is an iOS 26 feature, on apps whose deployment target doesn't start at iOS 26 the availability branching and fallback design make up half the work. Conversely, build that branching carefully and you can offer something that was genuinely hard for indie developers before: a timer that reliably rings even on silent. Start by getting the authorization request and a three-minute schedule() running once in your own project. Once that works, the rest is just refining the presentation.