Feedback: FB23754550 (filed July 14, 2026, still Open, no response)
App: AlarmWizard, com.UBSAnalyticsLLC.AlarmWizard, shipping on the App Store
Device: iPhone 17 Pro Max
Current OS: iOS 27.0 (24A5408d).
First seen on iOS 27.0 Seed 3 (24A5380h). Still reproducing on 24A5408d as of September 2, 2026.
Baseline: same app binary on iOS 26 release, same hardware, behaved correctly. No iOS 26 production user has reported any of the behaviors below.
Alarm under test: Alarm.Schedule.Relative, Mon through Fri, 07:05 America/New_York.
The app writes a timestamped file log of every AlarmManager.alarmUpdates emission, every BGTaskScheduler execution, and every scheduling call. All times below come from that log unless noted.
ISSUE 1: alarmUpdates .alerting transition is not delivered while the app is suspended. It queues until the app next gets runtime.
On iOS 26 the observer received .alerting at the scheduled minute with the app suspended (logged May 1 and May 6 at 06:35, the exact fire time). On iOS 27 the transition arrives only when the app next runs, almost always at unlock. Delivery lag for the 07:05 occurrence:
Jun 15: observed 08:50 (+1h 45m, unlock)
Jun 22: observed 09:15 (+2h 10m, unlock)
Jun 23: observed Jun 24 02:56 (+19h 51m, BGProcessingTask woke the app)
Jun 26: observed 17:22 (+10h 17m, unlock)
Jun 30: observed 12:12 (+5h 07m, unlock)
Jul 6: observed 09:08 (+2h 04m, unlock)
Jul 7: observed 09:00 (+1h 55m, app opened)
Jul 9: observed 07:06 (+81s, user unlocked right after dismissing)
The lag always equals time-until-the-app-next-ran, across three app builds. The Jun 23 case crossed midnight, so the event landed on the next calendar day.
Expected: .alerting delivered at or near fire time as on iOS 26, or documentation stating delivery is deferred to app runtime. Actual: delivery deferred up to about 20 hours.
ISSUE 2: the system alarm UI re-presents an occurrence hours after its scheduled time.
Jun 15: the 07:05 occurrence presented (lock screen alert with Snooze and slide-to-stop, plus sound) at 08:49. Lock screen screenshot attached to the FB.
Jun 30: the 07:05 occurrence presented at 14:25. Paired screenshots from the same minute show the system alert ("Work Week", 2:25) next to the app's full alarm list (a disabled 5:45 AM and the 7:05 AM Work Week alarm, nothing near 14:25). The observer logged alerting to scheduled at 14:25:48.
Expected: an alarm presents once, at its scheduled time. Actual: stale re-presentation up to 7+ hours late, and presentation of a disabled alarm.
ISSUE 3: with a Focus (Do Not Disturb) active, the alarm played audio with no lock screen presentation.
Jul 7, DND on overnight. At 07:05 the alarm sound played but no lock screen alarm UI appeared, only the indicator in the Dynamic Island. There was no way to stop it from the lock screen. Opening the app showed the alarm still in .alerting (our in-app firing UI appeared and the user stopped it there at 09:00).
Expected: full presentation (UI and audio) breaking through Focus, per AlarmKit's stated purpose. Actual: audio only, no lock screen UI.
ISSUE 4 (corroborating, no timestamped log): an AlarmKit countdown timer (AlarmManager.AlarmConfiguration.timer) presented its alert with no audio. The inverse of Issue 3. Presentation and audio appear to fire independently on iOS 27.
HOW WE ISOLATED THE OS
The identical binary ran on iOS 26 through early June with on-time delivery and no phantom presentations. The device was upgraded to the iOS 27 beta mid-June with no app change and the first stale presentation occurred Jun 15. Several internal builds since, including hardening for late delivery, changed nothing about the delivery lag. Every anomaly was checked against the log. Several suspected framework bugs were traced to our own code and fixed and are not reported here. In every case above, the log shows the app was suspended and received no callback at the relevant time, so the presentation, audio, and delivery behavior originated in the system.
ATTACHED TO FB23754550: three production log exports (Jun 22 through Jul 9), the Jun 15 and Jun 30 lock screen screenshots, and a sysdiagnose captured Jul 14 (sysdiagnose_2026.07.14_19-19-40-0400_iPhone-OS_iPhone_24A5380h). I can capture a fresh sysdiagnose on 24A5408d immediately after the next occurrence if a targeted profile would help.
Questions for Apple:
- Is deferred alarmUpdates delivery while suspended intended on iOS 27? If so, where is it documented, and what is the supported way to react to an alarm firing while the app is not running?
- Is there any known issue covering re-presentation of past occurrences?
- Is the Focus behavior in Issue 3 a known regression?
With the iOS 27 RC expected this month, I would appreciate confirmation that this is on someone's radar.
