When someone says an alarm did not work, start by recording what they noticed. An alarm that was never saved, an alert they did not hear, and a challenge that would not finish need different investigations. A support form should help you find that distinction without making the person diagnose your app.
I make Squatti, the NaguBuilds alarm app currently listed in the US App Store as Squat Alarm: Stop Snoozing. Its public flow includes setting an alarm and completing a camera-counted squat challenge. The template below is a proposed intake for app makers, not a report of a Squatti failure.
Start with a short first report
Apple's Feedback Assistant guidance asks for a specific issue, reproduction steps, expected and actual results, and relevant versions. For an alarm app, adapt those basics into this first message:
- App name and installed version, plus iPhone model and iOS version if known:
- What you expected the alarm to do:
- What you actually saw or heard:
- Intended alarm date, time and time zone, including repeat days:
- What you did just before the problem, including any alarm edit:
- Whether you have seen this before, and anything already tried:
Allow "I don't know" as an answer. If the person slept through the event, they may know only what was on screen later. Keep that observation intact. "I did not hear it" does not establish whether the phone displayed an alert.
Ask about impact in ordinary language: was one alarm affected, or is the person unable to use the app? They should not have to choose an engineering severity label.
Ask the next question at the uncertain step
Use the initial report to choose a follow-up. Sending every possible troubleshooting instruction at once makes it harder to know which condition changed.
- Saving: If the alarm was missing before its intended time, ask what appeared immediately after saving it.
- Scheduling: If the time or repeat day looked wrong, ask which next date the app displayed after the last edit.
- Alerting: If no sound was noticed, ask whether the person saw an alarm screen at the time, saw something later, or was not watching the phone.
- Challenge: If the alert appeared but the task did not progress, ask which challenge screen and count were visible, and whether a permission message appeared.
- Completion: If the task finished but another alert followed, ask for the sequence of visible screens and times, keeping uncertain times approximate.
These are investigation branches, not diagnoses. A permission check performed now records the current setting; it does not prove what that setting was when the reported event happened.
Squat Alarm's support page already describes its built-in Alarm Check and camera troubleshooting. If someone follows those instructions, add what they tried and the result to the report instead of assuming the issue is resolved.
Keep an observation separate from a theory
Here is a fictional example for the template, not a customer incident:
"I changed a weekday alarm yesterday. This morning I noticed the phone at 7:20 and did not hear an alarm. The app now shows tomorrow. I don't remember which date appeared after I saved the edit."
That leaves the scheduled date and the alert event unresolved. A useful next question is whether the person remembers the repeat days and intended time after the edit. "The system alarm service failed" would add a cause the report does not establish.
If they cannot remember, keep the field unknown and record the current setup separately. You can still investigate a clearly stated uncertainty.
Request only evidence that helps the next step
A cropped settings screenshot may answer a question about the selected repeat days. A camera recording of someone's room is a much larger request. Explain what detail you need and let them describe it in text when possible. Ask them to remove unrelated names, notifications and personal content before sharing an attachment.
Apple's bug-reporting advice describes screenshots, logs and small sample projects for developer reports. Decide which evidence fits the issue. A missing sound is not automatically an app crash, and a basic support intake does not need to collect a full device diagnostic by default.
Write the developer's next action
Finish the intake with a short internal note:
- Reported observation and unknown fields:
- Installed version and relevant setup:
- Follow-up question, if one is needed:
- Reproduction attempt to make on a test device:
- Result: not attempted, reproduced, or not reproduced under the recorded conditions:
Keep the person's report separate from your later test. A successful test should say what passed, not erase the original observation. Once an issue is understood, use the alarm app release checklist to decide which regression check belongs in the next release.
For the current public product and compatibility details, see Squat Alarm on the App Store.