Fix AlarmKit Permission Denied on iPhone (iOS 26)

Why does AlarmKit say permission denied?

AlarmKit shows a denied state because a person previously tapped "Don't Allow" on the alarm permission prompt, or because the Alarms toggle for that app got switched off later in Settings. Unlike notifications, there's no middle ground — an app is either authorized to schedule system alarms or it isn't.

Apple's own developer documentation lays out the three possible states an app checks before scheduling: switch AlarmManager.shared.authorizationState { case .notDetermined: // Manually request authorization case .authorized: // Proceed with scheduling case .denied: // Inform status is not authorized } If that switch lands on denied, the app has to tell the user the alert won't fire — it can't silently fall back to a regular notification. The mechanics behind this check are covered in more detail in what AlarmKit authorization actually approves.

A second, less obvious cause showed up during the iOS 26 betas: AlarmManager.shared.authorizationState always returns notDetermined, even when the app has previously been granted permission, which looks identical to a fresh denial until the app re-requests it. If an alarm app was built or tested on an early beta, that bug can masquerade as a permission denial that isn't really one.

How do I enable AlarmKit in Settings?

Open Settings → Notifications, tap the app, and toggle Alarms on. Per-app alarm control lives inside the Notifications settings screen rather than its own menu, which is Settings → Notifications → [App] → Alarms, toggled on or off per app.

The toggle is separate from every other permission on the phone. Users can revoke alarm permission per-app in Settings → Notifications, and AlarmKit alarms count toward a system-managed limit per app. Flipping the switch back on restores scheduling immediately — no reinstall needed. If you've never seen the prompt at all, re-opening the app and creating a new alarm is usually enough to trigger it, since authorization can be requested manually, or it will be requested automatically when you create your first alarm. The exact screen layout and what each toggle controls is broken down in what the AlarmKit setting actually controls.

Why doesn't the alarm ring after re-enabling permission?

Most apps need to detect the Settings change themselves, and poorly built ones only check authorization once at launch. AlarmKit exposes a live stream for exactly this reason — to listen to authorization state changes, apps use for await on authorizationUpdates, an AsyncSequence that emits events when authorization to use alarms changes. If the app isn't listening to that stream, it may keep showing a denied state in its own interface even though the system permission is already back on.

Force-quitting and reopening the app clears this in almost every case, because it forces a fresh read of authorizationState instead of a cached one. If alarms still won't fire after that, the problem is more likely a stuck notification setting than AlarmKit itself — worth comparing against calendar alerts breaking after an iOS update, which walks through a similar reset process.

Is AlarmKit permission the same as notification permission?

No — they're two separate authorization systems with their own prompts and their own Settings entries. Approving one has zero effect on the other, which is why an app can show notifications fine while still failing to ring an alarm.

This split matters most for apps that connect a calendar, since a calendar alarm app needs both notification access for sync status and alarm authorization for the actual alert. Pealo, for example, requests AlarmKit permission separately from calendar access so Google Calendar, Outlook, and iCloud events can still ring through Silent mode as real alarms rather than quiet banners.

Why is AlarmKit permission denied for a specific app only?

Permission is granted per app, not system-wide, so one alarm app being authorized has no bearing on another. Each app also has to declare its own usage string before the system will even show the prompt — developers must add NSAlarmKitUsageDescription to the Info.plist explaining how alarms are used.

If an app is missing that string, or ships without properly handling the denied case, the permission can appear broken when the real issue is the app's implementation. Apple's own session on the framework walks through the request flow end to end in Wake up to the AlarmKit API. For a broader rundown of what shipped alongside this permission model, see the full list of new alarm features in iOS 26, and if an app still won't request permission correctly after an update, contact support with the exact iOS version in question.