How an alarm app rings through Silent Mode

Everyone who starts an alarm app does the same first thing: schedule a timed notification with UNUserNotificationCenter. It works in the simulator, it works on the phone, it ships. Then a user writes: "It didn't ring on silent."

Because a notification is not an alarm. Its sound is at the system's mercy: Silent Mode cuts it, Focus delays or hides it, and it stops after 30 seconds anyway. Here is the structure that worked in Wakora:

1. Take the audio session and keep it

At alarm time the app opens an AVAudioSession and plays the alarm sound itself. That sound is not bound to the silent switch. The session stays open until the task is done. Background audio is declared in Info.plist, and you are genuinely playing audio; the "keep alive with a blank file" trick neither works nor passes review.

2. Keep notifications as the fallback, not the main path

If the app is swiped away, the audio session goes with it. So the notification chain is still scheduled: one at the alarm time, a backup a few minutes later. Worst case the user gets a silent-but-vibrating notification, which beats not waking at all.

3. Say when scheduling was interrupted

If scheduling was cut off for any reason, tell the user. Wakora shows a "alarm scheduling was interrupted, re-enable" warning on the home screen. An alarm app that fails silently collects one-star reviews.

4. Keep going after dismissal

Dismissing the alarm is not being awake. Two minutes later a "still up?" prompt catches going back to bed. That small screen became the most talked-about feature.

Measurement

After these four changes the "didn't ring on silent" review stopped appearing. Explaining the mechanism in one sentence during onboarding took day-one return from 16 to 30 points. Trust in an alarm app is not built by the loudest sound but by how many times it did not stay silent.