Alarm.Schedule.Relative gets scheduled to next day if too close?

Hi there,

Thank you for the framework 🙏

if I use Alarm.Schedule.Relative with Alarm.Schedule.Relative.Time(hour: hour, minute: minute) and Alarm.Schedule.Relative.Recurrence.never it seems like there is some (odd?) limit where alarm will get scheduled to next day if too close?

For example, lets say the current time is 12:00 PM, if I schedule alarm for 12:02 PM, it will schedule it for next day, while if I do 12:05 PM it will work as expected.

Is that expected? If yes, what's the behavior and is that documented anywhere?

I would expect any alarm thats scheduled in the future to fire for the current day (maybe if it's only 1 minute it gets tricky).

One problem is also that even if the framework says an alarm is scheduled, I don't have access to the "next alarm date"? I wish I did as otherwise I have to compute it (by "guessing" the AlarmKit calculation) if I want to do anything with that date.

Honestly, sometimes I think I am just going crazy when the alarm doesn't fire, but there SEEMS to be some odd behavior around this?

(of course, feel free to correct me on anything - I could be missing documentation or not understanding something)

If you're certain you are not mixing up the time zones between real time and alarm time, this would be worth filing a bug report about.

Bug Reporting: How and Why? has tips on creating a successful bug report.

If you can, please include a sample project that reproduces this, and in case it is specific to your environment, It would be very helpful if you could please go to https://developer.apple.com/bug-reporting/profiles-and-logs/ and follow the instructions for sysdiagnose for iOS to create a sysdiagnose. And attach that to the Feedback report as well.

Once done let me know the Feedback ID, and I'll forward it to the AlarmKit team.


Argun Tekant /  DTS Engineer / Core Technologies

Hi there, thank you for the response.

At the moment, I am not 100% clear on what's going on so don't want to go through the process of filing Feedback.

My "updated" understanding is that the alarm maybe does go off, but there's some special behavior if the phone is not locked (ex. its in "foreground") or app is in foreground while the alarm goes off.

If I lock my phone, even with 1 minute differential I see the alarm go off.

If I don't lock my phone, what maybe happens (at least I sometimes see it in debugger) is that the app runs to receive the "alerting" update (even if its technically in background?), but there's no UI anywhere showing that the alert is going off. Sometimes I do hear the sound (there's sound of alarm going off with no UI anywhere).

I utilized open source sample code around AlarmKit and for that I do see the UI appear, where maybe it does because they implemented the custom widget? (but even their UI still shows inconsistencies depending on state of device/app)

Of course I could be confused (surely am somewhat!), but my wish is that it would just always show UI (Lock Screen or "notification") / play sound, no matter what state there is.

for the same code (didn't change anything - just keep toggling same app code 1 minute apart):

  1. If I set alarm 1 minute later and lock the phone -> I see alarm go off and UI shows in Lock Screen with the alarm sound
  2. If I set alarm 1 minute later and do NOT lock the screen (looking at Home Screen while I wait) -> I get nothing (likely my app code is executing something though)

without fail it does that behavior atm

Alarm.Schedule.Relative gets scheduled to next day if too close?
 
 
Q