An alarm app release check should follow one alarm from creation to its final outcome. Verify permission, the saved schedule, the actual alert, what the person does next, and whether the app cleans up correctly afterward. A screenshot of an enabled switch cannot establish all of that.
I make Squatti, the NaguBuilds alarm app currently listed in the US App Store as Squat Alarm: Stop Snoozing. Its camera-counted squat challenge makes the distinction between stopping a sound and finishing a task especially relevant.
This is a proposed test plan for developers. Each result starts blank; fill it from the build and device you actually test.
Write the expected outcome before running the test
Start with the behavior your interface promises. When someone enables an alarm, what exactly have you confirmed? After they change the time, which schedule should exist? When they finish the alarm's task, what should remain scheduled?
Apple's AlarmKit introduction covers authorization, schedules and the alarm lifecycle. It also explains that people can change alarm authorization in Settings. Those platform capabilities are a starting point for your test plan; they do not prove your own state handling is correct.
For each case, write a visible outcome and, where your development tools allow it, the corresponding system state. Keep these observations separate. The app can display the right time while the wrong alarm remains scheduled.
Test permission changes as part of normal use
Work through a fresh permission decision, a denial, and a later change in Settings. Check the message the person sees in each state.
- Before permission is granted, does the interface explain what the app needs?
- After denial, does it clearly distinguish a saved alarm preference from an alarm that can alert?
- After permission changes, does the visible state update without requiring the person to guess?
- If scheduling fails, does the app retain an honest state and a useful next action?
Apple's AlarmKit scheduling sample demonstrates requesting authorization. Use it to verify the platform flow, then inspect how your own app presents success and failure.
Follow a schedule through edits and cancellation
Create a test alarm with enough time to observe the complete flow. Record its original time and identity. Change the time, then disable it. Check that the earlier schedule cannot surprise the tester later.
Repeat with a recurring alarm. Include an edit to its selected days and a case where the next intended day differs from today. Read the next-alarm text as a person would: does it name the expected day and time?
If your product supports travel or time-zone changes, write down the intended policy before testing. Apple distinguishes fixed-date schedules from relative schedules in its AlarmKit session. Test the schedule type you actually use instead of assuming every alarm follows local clock time in the same way.
Observe the alert on a physical device
Record the iPhone model, iOS version and app build. Run cases in the device states your app claims to support, including a locked screen and the relevant Silent mode or Focus configuration. Check the sound and controls that really appear.
Keep a record of what you observed. A simulator walkthrough can help review screens; it does not demonstrate a physical camera flow or the sound on the tester's phone.
For an alarm with an additional task, test each available path from the alert. Stopping the current alert, opening the app, completing the task and taking an escape path may represent different product outcomes. Define them separately.
Do not write acceptance criteria such as "the alarm is impossible to bypass." Test what your app controls, document what iOS controls, and make the user-facing explanation match.
Treat task completion and cleanup as one case
For a camera task, include permission denied, an interrupted camera session and an incomplete task. The test should establish what the person can do next, not merely whether a counter animates.
Then finish a task and inspect the aftermath. Does the completed state survive reopening the app? Does the history record agree with what happened? Are any related follow-up alarms still pending? If the product has an emergency exit, verify its visible consequences too.
Squatti's current public listing describes a squat target, camera counting and Emergency Skip. Those are useful examples of distinct paths to put in a plan. They are not interchangeable definitions of a completed wake-up.
Copy this release test record
Use one copy for each scenario. A blank result is an unfinished test.
- Case name:
- App build, device and iOS version:
- Permission and device settings before the test:
- Alarm time, recurrence and relevant task settings:
- Action performed:
- Expected visible result:
- Expected system or persisted state:
- Actual alert and controls observed:
- Actual task outcome:
- State after reopening the app:
- Remaining scheduled work:
- Evidence location and test time:
- Pass, fail or not tested:
- Follow-up needed before release:
Keep evidence from a real run beside the record. Avoid using a completed animation, log line or API response as proof of parts of the flow it did not observe.
Pick the release decision from the evidence
Choose the cases that protect your product's actual promises. An alarm that cannot be cancelled correctly needs attention before release. So does a camera task with no understandable recovery path.
After a change, rerun the affected cases and retain the earlier result. If you cannot test a supported device state, record the gap explicitly. Do not turn "not tested" into a pass to finish a checklist.
If you want to see the product behind this example, Squatti's current App Store listing is under Squat Alarm. The checklist is intended to help you review your own alarm flow, whatever task it uses.