The iOS Permission Almost No Alarm App Is Allowed to Use

Apple ships a notification tier called Critical Alerts that can override a muted phone, an active Do Not Disturb schedule, and every Focus mode a user has configured. It exists specifically to solve the problem every alarm developer runs into — a notification that has to reach someone no matter what their phone’s settings say. Almost no alarm app is allowed to use it, and the reason has nothing to do with engineering effort and everything to do with what Apple decided the permission is for.

What Critical Alerts actually is

In Apple’s push notification framework, every notification carries an interruption level: .passive, .active, .timeSensitive, or .critical. The first three are things any developer can set. .critical is not — it requires a special entitlement that Apple grants manually, and it’s the only level that ignores the mute switch, Do Not Disturb, and Focus filtering simultaneously. A .critical notification plays sound at a volume the user can’t fully silence short of powering the phone off.

That’s an unusually powerful capability to hand a third-party developer, and Apple treats it that way. The entitlement request form asks for the app’s category and use case, and approval leans almost entirely toward a narrow set of purposes: medical alert systems (a glucose monitor warning of a dangerous reading, though getting that warning past a muted phone turns out to be the easier half of actually waking someone up), home security (an alarm company’s intrusion notification), and public safety. Space-weather apps, whose entire pitch is waking someone the moment a rare forecast crosses a threshold, ask for the same override and get declined for the identical reason a general alarm app does. Apple’s own developer documentation frames the bar as “critical alerts should be used only for exceptional situations” — and an app whose entire purpose is exceptional situations, several times a week, by design, is not what the review team has in mind.

An alarm app is, definitionally, asking for the same override every single morning. That’s a routine use of an emergency-tier permission, and it reads to Apple’s review process less like a safety feature and more like a way to guarantee engagement regardless of what the user’s settings say. Declined.

Why the built-in Clock app doesn’t need it

This is the detail that makes the whole system feel inconsistent if you haven’t looked under the hood: Apple’s own Clock app alarms already bypass Do Not Disturb and Focus, without Critical Alerts. They can do that because they aren’t notifications at all in the third-party sense — they’re a system-level process running with privileges no App Store app can request, the same tier that lets an incoming phone call ring through a muted phone. Apple built an exemption for its own alarm feature into the operating system’s architecture, then built a much narrower, harder-to-get exemption for everyone else’s.

The practical result, for most of iOS’s history, was a two-tier reliability system baked into the platform: Clock app alarms sound no matter what Focus says, and everyone else’s ability to sound depended on notification permissions a user could accidentally misconfigure. That gap narrowed, but didn’t close, with iOS 26.

AlarmKit closed part of the gap — but only for the alarm itself

iOS 26 shipped AlarmKit, a framework built specifically for alarm-clock functionality, and it’s the closest thing to a real fix third-party developers have gotten. An app built on AlarmKit gets the same automatic Focus-bypass as the Clock app — no entitlement request, no manual allow-listing, no .timeSensitive permission toggle a user has to remember to flip. For the single, narrow job of “this scheduled alarm needs to sound,” Apple effectively extended the Clock app’s system-level privilege to any developer willing to adopt the framework, which is a meaningfully different posture than the Critical Alerts gate it sits next to.

The scope is the catch. AlarmKit covers the alarm-firing moment — the equivalent of the Clock app ringing at 6:15. It doesn’t extend to everything an accountability or wake-up app needs beyond that single event: a follow-up nudge if the first alarm goes unanswered, a notification to a friend that someone hasn’t checked in, an escalation message on a completely different channel. Those are still ordinary notifications, still subject to .timeSensitive filtering, and still gated behind Critical Alerts if a developer wants them to punch through Focus the way the base alarm now can. AlarmKit solved the part of the problem that looks like a clock. It left the part that looks like a conversation between people exactly where it was. Even that narrow alarm-firing moment kept getting patched after the fact — iOS 26.4 fixed a separate routing bug where an alarm on a paired Apple Watch worn to bed could fire only on the watch, silently, if the watch itself was in Silent Mode, a reliability fix worth knowing about alongside AlarmKit.

The workaround for everything AlarmKit doesn’t cover

For apps that haven’t adopted AlarmKit yet, or for the escalation layer AlarmKit was never scoped to handle, developers lean on .timeSensitive — the notification tier available without special approval, which Focus modes respect by default but which a user can explicitly permit per app in Settings. Combine that with an active audio session (the same API category media and navigation apps use to keep sound playing in the background) and you get something that behaves like an alarm most of the time, for most users, on most configurations. That background audio session is also the reason alarm-adjacent apps tend to use more battery overnight than a passive app — a tradeoff covered in more detail from the user side — since keeping an audio session alive is a heavier ask of the OS than a silent background process.

“Most” is doing real work in that sentence. The failure mode isn’t rare: a user updates iOS, a Focus mode’s allow-list resets or wasn’t configured to include the app in the first place, and a .timeSensitive notification that would otherwise have sounded gets silently filtered. Nothing crashes. No error appears. The notification simply doesn’t arrive, and nobody finds out until whatever the alarm was for has already been missed — which is the exact failure walked through step by step, from the user side, in the troubleshooting guide for a silent iPhone alarm.

This is also, worth noting honestly, a genuine limitation of building on the platform rather than a flaw unique to any specific app: no third-party developer can fully close this gap for anything outside AlarmKit’s narrow scope using publicly available APIs. The closest a developer can get is aggressive onboarding that walks a user through manually exempting the app from Focus and Do Not Disturb — a UX tax that exists purely because the permission that would make it unnecessary isn’t available to them for anything beyond the alarm itself.

Android’s version of the same fight

Android solved this with a lower, more accessible bar and then spent several OS versions raising it back up. SCHEDULE_EXACT_ALARM and full-screen intents let any developer schedule a precisely timed wake event that can launch a UI over the lock screen with sound — architecturally closer to a system alarm than iOS’s .timeSensitive tier, and historically available without a special review process.

Android 12 and 13 tightened this considerably, moving exact-alarm scheduling behind a runtime permission the user has to grant per app, specifically because the openness had been exploited by apps using exact alarms for reasons that had nothing to do with waking anyone up — background refreshes disguised as alarms, mostly, to dodge battery optimization. The fix for that abuse looks, from an alarm developer’s chair, a lot like Apple’s Critical Alerts problem: a platform tightening a powerful permission in response to misuse elsewhere, with legitimate alarm apps caught in the same net as the apps that caused the tightening.

Neither platform’s current design is arbitrary. Both are responding to the same underlying tension — a notification tier powerful enough to override a user’s explicit silence settings is also powerful enough to abuse, and the group best positioned to abuse it (any app that wants attention) overlaps heavily with the group that has a legitimate reason to need it (apps whose entire function is not being ignorable). Apple and Google have drawn that line in different places, but they’ve both drawn it well short of “any alarm app that asks gets it.”

What this means if you’re evaluating an alarm app’s reliability

The base alarm is a mostly solved problem now, for any app that’s adopted AlarmKit — but everything that app does after the alarm fires, including the escalation and social-accountability layer that separates a plain alarm clock from something like this site’s subject matter, still runs on the older, leakier .timeSensitive path. What separates a well-built app from a poorly built one isn’t access to a permission neither has for that second layer — it’s whether the app actively teaches users to configure the Focus allow-list correctly during onboarding, rather than assuming a .timeSensitive notification will behave like a system alarm by default. If an app never mentions Focus mode during setup, that’s usually a sign nobody on the team hit this wall in testing.