What Shipping on iOS 26 AlarmKit Actually Decided For Us

📋 Key Summary

AlarmKit: the system alarm API Apple introduced in iOS 26. Third-party apps can now fire alarms through the same path as the Clock app.
Before it: a third-party alarm app had exactly one delivery path — a notification — and a notification cannot make a sound while the ringer switch is on Silent.
Decision 1: drop iOS 18 and earlier entirely, rather than ship an alarm that might stay quiet.
Decision 2: when the system alarm permission is denied, fall back to notifications but label the alarm so the difference is never hidden.
Limits: AlarmKit has no watchOS support yet, and the first system alarm sound is played by iOS, so it cannot be faded in.

🤖 AI Summary

Before iOS 26, third-party alarm apps carried a structural problem. There was exactly one way to fire an alarm — a local notification — and notifications are subject to the ringer switch. If someone sleeps with their phone on Silent, a notification-based alarm has no way to make a sound. That single fact explains a large share of the “it didn’t go off” reviews on every alarm app in the store.

AlarmKit, introduced in iOS 26, changes the shape of the problem. Third-party apps can now schedule system alarms, so with the permission granted an alarm fires through the same path as Apple’s own Clock app: through Silent mode, through Focus, full screen on the Lock Screen.

This article is about the decisions that followed, not about API syntax. It covers why we dropped every iOS below 26, how we handled the fact that behaviour changes with the permission combination the user grants, and what AlarmKit still does not solve. The theme running through all of it is that a new capability mostly bought us the obligation to be clearer about our limits.

What AlarmKit changed

AlarmKit is the system alarm API Apple introduced in iOS 26. The important part is simple: third-party apps got a second delivery path.

Until then the only option was a local notification. Notifications work well for what they are, but as an alarm mechanism they have one decisive weakness — with the ringer switch on Silent, there is no way to produce sound. A meaningful share of people who install alarm apps sleep on Silent, and some of them assume the app will get through anyway. It could not.

Grant the system alarm permission and the alarm fires on the same path as the Clock app: through Silent, through Focus, full screen on the Lock Screen. What Apple’s own app could do, third parties can now do too.

Decision 1: no iOS below 26

This was the biggest and the most arguable one. Raising the deployment target to iOS 26 means writing off a large part of the addressable market, which is not a comfortable thing for a new app to do.

The reasoning was this. On iOS 18 and earlier there is no AlarmKit, so a notification is the only way to fire — and with the ringer switch on Silent, a plain notification has no way to make a sound. In other words, on older versions we could only ship an alarm that might or might not go off.

For an alarm app that is not a missing feature, it undermines the reason the product exists. People sleep on the assumption that it will work. If that assumption is conditional, they are better off not installing it.

Anyone who already installed on an older version keeps the last compatible build, under App Store policy. Existing users are not cut off; only new distribution moves to iOS 26.

There was a secondary benefit. Removing the legacy path removed a whole class of “on this path do X, on that path do Y” branching. In a domain where a failure translates directly into someone missing a flight, fewer branches is worth something on its own.

Decision 2: two permissions, and what each one buys

The app requests two permissions, and it mattered to be precise about what each one actually gets you.

System alarm (AlarmKit)

Granted, alarms ring on the same path as Apple’s Clock app — through Silent mode and through Focus, full screen on the Lock Screen. This is the behaviour people actually expect from an alarm app.

Notifications

Granted, you can add the app to the allowed-apps list under Settings › Focus. It also becomes the delivery path when the system alarm permission is off.

What each combination does

This is where the design got awkward. The outcome depends on which combination the user grants.

Permission granted	How the alarm is delivered	Ringer switch on Silent
System alarm (AlarmKit)	Same path as the Clock app, full screen on the Lock Screen	Rings
Notifications only	Delivered as a standard notification	Makes no sound
Neither	Cannot ring	—

Either one on its own is enough for the alarm to ring. But denying the system alarm permission means delivery drops to a notification, so it makes no sound while the ringer switch is on Silent.

Deny both and the alarm cannot ring at all. In that case the app warns before saving — but does not block the save. The user may grant the permission later, and refusing the save would only force them to build the alarm again.

Decision 3: never hide which path an alarm is on

An alarm that fell back to the notification path is labelled as such in the list. We did not let it quietly behave differently.

This makes the UI worse. A list with no badges is cleaner. We label it anyway, because if an alarm is not going to make a sound, the user needs to learn that the night before, not the morning after.

The worst failure mode for an alarm app is a silent one. The user believes the alarm is set, the app is in a state where it cannot produce sound, and the gap only becomes visible once someone has overslept. One line of text in a list is a very cheap way to close that gap.

What AlarmKit still cannot do

No watchOS

AlarmKit does not support watchOS yet. iPhone alarms mirror to the wrist under the system’s own rules and the Live Activity shows up in the Watch Smart Stack, but there is no standalone Watch alarm, and the mission has to be finished on the iPhone.

This is the kind of item that is tempting to put on a roadmap. It is not an engineering problem though — it is an OS-level constraint, so it cannot be promised until Apple ships AlarmKit for watchOS.

The first sound belongs to iOS

We found this one while building a gentle wake-up fade. The first sound of a system alarm is played by iOS, so the app cannot fade it in. What the app controls starts after that.

Small, but it forces the feature description to be honest. Writing “wakes you gently” without qualification sets up an expectation that the very first second breaks.

The firing path is not yours

Less a limitation than a shift in mindset. Adopting AlarmKit means handing a good deal of control over the firing moment to the OS, and getting reliability in exchange. The app’s job is to layer missions and records on top — not to reimplement the alarm.

A rule: never work around an iOS setting

There is a ringing escalation that raises the volume after a stretch of no response. It only touches the app’s own audio, and never works around an iOS setting.

That line was drawn deliberately. Build an alarm app for any length of time and the temptation to find a trick that “makes it ring no matter what” shows up. That road ends either in review rejection or, worse, in software that takes control of the device away from its owner. Cutting through Silent and Focus should come from a permission the user granted, not from a workaround.

The same rule shapes the delete-protection feature. It uses Screen Time to hide the delete option while an alarm is ringing, but that is one layer against a half-asleep finger, not an absolute block — Screen Time can be turned off at any time. The documentation says exactly that.

An alarm is still an aid, not a certainty

AlarmKit reduces the situations in which an alarm cannot ring. It does not eliminate them.

A powered-off phone, a drained battery, a denied permission, limits imposed by the OS. No alarm app prevents those. So for anything that genuinely matters, the guidance is to also set a backup alarm in the system Clock app.

Pointing users at a competing feature sounds strange. But what an alarm app sells is trust, not features, and trust comes from stating the limits first. Telling someone who overslept that the app did its best is worse than having told them to set a backup in the first place.

Wrapping up

AlarmKit gave third-party alarm apps something they had gone without for a long time: grounds to say the alarm will actually ring.

In exchange it asks for a new kind of honesty. Behaviour varies with the permission combination, watchOS is not there yet, the first sound belongs to the OS. Writing those into the documentation and the UI took as much thought as wiring up the API.

If you are building anything alarm- or timer-shaped on iOS 26, the advice is to design how you will explain the permission combinations before you design anything else. That part took longer than the code.

The decisions here came out of building AlarmK, a mission alarm app for iPhone. The per-permission behaviour is written up separately on its AlarmKit page.