What does the AlarmKit permission prompt say?
It's a one-time system dialog that shows the app's own explanation text, not a generic Apple sentence. Setting up authorization requires adding NSAlarmKitUsageDescription to the app's info plist explaining the use case for presenting alarms, with a short and descriptive explanation of how the app will use alarms, to help people make the best decision. That string is written by the developer, so the prompt for a wake-up app reads differently than the prompt for a pomodoro timer, even though both are asking for the same underlying permission.
The trigger timing is developer-controlled too. To request authorization manually, developers use the AlarmManager requestAuthorization API, and if a choice has not previously been made, a prompt is shown containing the usage description. Some apps ask during onboarding; others wait until the first time someone actually schedules an alarm. Pealo asks at the point someone connects a calendar and sets their first alert, so the request has obvious context rather than appearing on a blank first screen.
How is AlarmKit permission different from notification permission?
They're two separate systems with two separate prompts, and granting one says nothing about the other. Both frameworks require permission — for local notifications, the call is requestAuthorization(options:completionHandler:), while AlarmKit uses its own path entirely. The Alarm also needs permission, but the requestAuthorization() method doesn't accept any options the way the notification API does.
Functionally the gap is bigger than the API difference suggests. Notifications can be muted by Focus, downgraded by Silent mode, or buried in a notification stack. The difference is covered in more depth in AlarmKit vs Notifications: why alarms ring louder, and in Alarm vs Reminder vs Notification on iOS for the terminology side of it.
| Behavior | Notification permission | AlarmKit permission |
|---|---|---|
| API entry point | UNUserNotificationCenter.requestAuthorization | AlarmManager.shared.requestAuthorization() |
| Info.plist key | None required by default | NSAlarmKitUsageDescription |
| Rings on Silent | No | Yes |
| Breaks through Focus | Only Time-Sensitive | Yes, by default |
| Settings location | Settings → Notifications → App | Settings → Notifications → App → Alarms |
| Options passed to prompt | Badges, sounds, alerts flags | None — single yes/no |
What happens if someone taps Don't Allow?
The app can still create alarm objects in code, but none of them will ever fire. If authorized, the app can proceed with scheduling the alarm; if denied, it's important for the app's interface to make it clear that the alarm will not be scheduled. There's no silent fallback to a regular notification — Apple expects the app to tell the user directly that the alert won't happen.
A denial isn't permanent. People can reverse it from Settings, and the app can detect the change without forcing a relaunch. Listening to authorizationUpdates, an AsyncSequence, emits events when authorization to use alarms changes, so an app that was denied can pick up a later approval automatically. This is the same pattern behind the fixes in Calendar notifications not working on iPhone, where a revoked permission — not a sync bug — is often the actual cause.
Can an app check alarm permission without showing a prompt?
Yes — reading the status is separate from requesting it. The pattern is a switch over AlarmManager.shared.authorizationState with three cases: notDetermined, authorized, and denied. Checking this value never shows UI; only calling requestAuthorization() does, and only while the state is still notDetermined.
This two-step split matters for app design. An app can silently check status on launch to decide whether to show a "turn on alarms" banner, and only fire the real system prompt when the person taps a button to act on it. The user controls the privilege via a system permission prompt the first time the app schedules an alarm, so a well-built app times that first schedule attempt to a moment the user already expects it — right after picking a calendar event to alert on, for example.
Where do you turn AlarmKit off for one app?
It's a per-app toggle inside the Notifications settings screen, not a separate Alarms section. To allow or revoke AlarmKit access, go to Settings → Notifications → the app → Alarms, and toggle it on or off. This keeps alarm permission grouped with the rest of an app's alert settings instead of scattered across Settings.
Revoking it doesn't delete alarms already scheduled from the UI, but it does stop them from ringing going forward, which is why apps that depend on AlarmKit — including Pealo's calendar alarm app — check authorizationState before every new schedule rather than trusting a cached "was granted once" flag. AlarmKit alarms also count toward a system-managed limit per app, which is a separate constraint from the permission itself. For a deeper look at what counts as a "critical" alert versus a standard AlarmKit alarm, see Critical Alerts vs AlarmKit alarms on iOS.
Why does Apple require a separate permission from notifications at all?
Because AlarmKit grants a capability notifications never had — sound and full-screen UI that override Silent mode and active Focus sessions. Because an AlarmKit timer ends with an alert that plays sound and appears even when a Focus is active, the app must ask the user for explicit permission separate from the lighter-weight notification grant. Apple treats that override capability the same way it treats camera or location access: powerful enough to need its own explicit yes.
The framework itself was introduced to close a long-standing gap third-party apps had against Apple's own Clock app, which is covered from the ground up in What is AlarmKit, and why does it matter?. Before iOS 26, no third-party calendar app could legally ring through Silent mode the way Clock does — that's also why the comparison in Time-Sensitive Notifications vs AlarmKit is worth reading if the distinction still feels blurry.
Alarms your calendar sets for you
Connect Google, Outlook or iCloud. Pealo arms a real alarm before every event.
Download on the App Store