Where is the AlarmKit permission in Settings?
It lives inside each app's own notification page: Settings → Notifications → [App Name], where an "Alarms" row sits separately from the usual Allow Notifications switch. There's no single master list of every app that holds AlarmKit access the way there is for Camera or Microphone — the permission is scoped per app, and it only shows up once that app has actually asked for it.
That's a deliberate design choice. Users can change authorization in Settings anytime, but Apple doesn't surface the row until the app has triggered a request, which usually happens the first time someone tries to schedule an alarm inside it. If you've never used the alarm feature of an app, don't expect to find the toggle yet. For a plain-language walkthrough of what the initial prompt itself says, see AlarmKit authorization, what users approve.
What does turning off "Schedule Alarms and Timers" actually do?
Turning it off blocks the app from creating new system-level alarms — the kind that ring through Silent mode and Focus — while leaving its regular notifications untouched. Because an AlarmKit timer ends with an alert that plays sound and appears even when a Focus is active, the OS requires explicit permission for it. Flip the switch off and that specific capability disappears; everything else about the app keeps working.
If the user denies permission, the app can't schedule AlarmKit timers, and depending on the app, it may disable timer-related features and direct users to Settings to enable them, or fall back to another timing method. Apps don't crash or lose data when this happens — they're just left with ordinary notifications, which can be silenced by Focus or the mute switch. That's the entire functional gap this toggle creates, and it's covered in more depth in critical alerts vs AlarmKit alarms.
What are the three AlarmKit authorization states?
Every app sits in one of three states — not determined, authorized, or denied — and only one of them lets alarms actually ring. The authorization process involves adding a usage description to the app's Info.plist, and the framework provides three authorization states: notDetermined, authorized, and denied, allowing developers to create appropriate experiences for each scenario. "Not determined" means the app has never asked, or the person has never responded to the one-time prompt.
| State | Settings toggle shown? | New alarms ring? |
|---|---|---|
| Not Determined | No | No |
| Denied | Yes, switched off | No |
| Authorized | Yes, switched on | Yes |
Apps are supposed to re-check this state before every scheduling attempt rather than assume it's stuck where it was. Developers have flagged edge cases where the status query lagged behind reality after an early iOS 26 beta, which is a separate bug from anything a user controls in Settings.
How is the AlarmKit toggle different from the notification permission?
They're two entirely separate systems that happen to live on the same Settings page, and granting one tells iOS nothing about the other. They're two separate systems with two separate prompts, and granting one says nothing about the other — both frameworks require permission, but for local notifications the call is a different API path than the one AlarmKit uses. A person can allow notifications for an app while leaving its Alarms toggle off, which is actually the most common configuration for apps that haven't adopted AlarmKit at all.
The practical difference shows up the moment Silent mode or a Focus is active. Notification permission alone won't make a sound play under those conditions unless the alert is marked time-sensitive, and even then it's a lighter-weight interruption than a true alarm. AlarmKit vs notifications covers why the loudness gap exists at the system level, and what AlarmKit is built to do covers the framework itself for anyone encountering the name for the first time.
Why would an app lose AlarmKit permission after an update?
It almost never does on its own — a major iOS update can reset notification styles or re-enable a Focus, but AlarmKit authorization itself is tied to the user's explicit choice and typically survives updates untouched. What actually trips people up is confusing the two: a calendar or alarm app that suddenly feels quiet usually has its sound or Focus settings reset, not its AlarmKit toggle flipped. Calendar notifications not working on iPhone walks through that broader troubleshooting checklist.
Reinstalling an app, however, does reset the permission to "not determined," since authorization is stored against the app's installation, not against an Apple ID or iCloud account. The next alarm scheduling attempt triggers the one-time prompt again. This is the same reason sideloaded TestFlight builds and production App Store versions of the same app sometimes show separate authorization states on one device.
What should you check if an app's alarms stop ringing?
Check the app-specific Alarms toggle first, since it's the single point of failure that silences every alarm from that app regardless of what else is configured correctly. Go to Settings → Notifications → [App Name] and confirm Alarms is switched on; if it's off, the app can still display alarms inside its own interface, but none of them will actually sound.
From there, work outward: confirm the device isn't in a Focus that's filtering the app separately (Focus filters are a distinct layer from AlarmKit authorization), check that the physical mute switch or Ring/Silent setting hasn't been misread as a blanket mute, and confirm the app itself has an alarm actually scheduled rather than just a notification reminder. For calendar-specific alarm apps like Pealo's iPhone alarm app, this three-layer check — app permission, Focus, device volume — resolves the overwhelming majority of "my alarm didn't go off" reports.
Alarms your calendar sets for you
Connect Google, Outlook or iCloud. Pealo arms a real alarm before every event.
Download on the App Store