Miracle Alarm

What it is

A morning alarm that does not have an off button. It has a question. The alarm keeps ringing until you say the answer out loud, and the act of forming a sentence is what actually wakes you — not the act of reaching for a phone.

There is no snooze. Not a longer snooze, not a limited snooze. The product decision is that snooze does not exist, because a snooze button is the thing the rest of the design is built to remove.

Why this experiment

The interesting constraint is not the idea, it is the platform. Cross-platform is a hard requirement here, not a preference — an alarm that exists on only one operating system is a demo, because the person who needs it owns whichever phone they already own.

That requirement is what made this worth running as a spike. On iOS, an alarm that must survive, keep sounding, and only stop on an explicit instruction sits close to the edge of what the system will allow.

How it works

The stack is Flutter with six self-authored native plugins — scheduler, presenter, audio, speech, TTS, and permissions — at roughly 65% shared code. Speech recognition and speech synthesis both run on-device only: no server, no API cost, and nothing spoken at 6am leaves the phone.

The finding that makes the iOS side work is specific and was validated directly: an AlarmKit alarm keeps ringing even after the user opens the app through a custom “Start” button. It stops only when AlarmManager.shared.stop(id:) is called explicitly. So the lock screen carries one button, “Start”, and every question happens inside the app while the alarm is still sounding.

This overturned an earlier conclusion that iOS was impossible. That analysis was not wrong so much as answering a different question: it assumed the entire flow had to happen on the lock screen. Once the requirement changed to “tap Start, then proceed in the app”, the premise it rested on was gone.

The last question — what is the first thing you will do today? — is asked after the alarm is already off. It is optional, and not answering it still leaves the alarm off. A question that can re-trigger an alarm is a punishment, and this is not that.

The first-run tutorial opens on the real alarm screen with no explanation. The user answers three questions by voice, those answers are saved as their answers, and the typing fallback is taught in the same place — so the first time the alarm fires for real, nothing about it is new.

Where it is now

Spike phase, as of 2026.09. The core iOS behaviour is validated; the design stands on it.

One known unknown is open and it is a real one: AlarmKit’s automatic silence timeout is undocumented by Apple and has to be measured on a real device. Related, stopIntent is reported not to fire on swipe-dismiss — so alarm-end detection cannot be built on it, and is not.

The iOS deployment target is 26.0 and cannot be backported. Custom questions are out of the MVP; they are a Post-MVP candidate for a Pro unlock.