Description
Environment
Loop: next-dev
Built via: GitHub Browser Build (Fastlane)
Branch updated: Current next-dev (built current commits as of July 31, 2026 12:11CDT)
iPhone 17 Pro Max
iOS 26.4.2
Omnipod 5
Libre 3+ native BLE support
Summary
With the new native Libre glucose alerts in next-dev, the configured glucose alert sound is ignored.
The alert is delivered as an iOS Critical Alert, but it always plays the system default Critical Alert sound (Radial on my device) rather than the sound selected in Loop.
Steps to reproduce
Build the latest next-dev.
Configure a custom sound for Critical Low (or High) glucose alerts in Loop (for example Urgent Low).
Verify the sound preview in the settings screen.
Trigger either:
a real glucose low, or
Loop's "next reading as low" test.
Observe the alert sound.
Expected behavior
The glucose alert should use the sound selected in Loop (for example "Urgent Low").
Actual behavior
The notification is delivered as a Critical Alert, but always plays the iOS default Critical Alert sound (Radial).
This occurs for both:
simulated/test glucose alerts
actual glucose low alerts
Additional observations
Critical Alerts are enabled in iOS.
Notifications correctly bypass Silent Mode and Focus.
The selected sound previews correctly inside Loop.
Changing the selected sound has no effect on actual glucose alerts.
Rebuilding from the latest next-dev does not change the behavior.
Investigation
While debugging this locally, I noticed that Libre glucose notifications appear to be generated by:
LibreTransmitter/NotificationHelper.swift
Within NotificationHelper.addRequest(...), critical alerts always assign:
content.sound = .defaultCriticalSound(withAudioVolume: ...)
rather than a named critical sound.
Because of this, it appears that the configured glucose alert sound is never used for Libre glucose alerts.
The notification is correctly marked:
content.interruptionLevel = .critical
but the sound is always assigned via:
.defaultCriticalSound(...)
instead of a user-selected sound.
I wasn't sure if this is intentional while the new Libre alert implementation is under development, or if it's an oversight. I'm happy to test a fix or provide additional information if helpful.
One additional note, while reviewing the code, I also noticed:
Float(criticalVolume / 100)
If criticalVolume is an integer, values between 60–99 would evaluate to 0 before conversion. I'm not sure of the type of mmCriticalAlarmsVolume, so this may or may not be an issue, but it caught my eye during review.
Loop Report 2026-08-01 22_22_25-05_00.md
Description
Environment
Loop: next-dev
Built via: GitHub Browser Build (Fastlane)
Branch updated: Current next-dev (built current commits as of July 31, 2026 12:11CDT)
iPhone 17 Pro Max
iOS 26.4.2
Omnipod 5
Libre 3+ native BLE support
Summary
With the new native Libre glucose alerts in next-dev, the configured glucose alert sound is ignored.
The alert is delivered as an iOS Critical Alert, but it always plays the system default Critical Alert sound (Radial on my device) rather than the sound selected in Loop.
Steps to reproduce
Build the latest next-dev.
Configure a custom sound for Critical Low (or High) glucose alerts in Loop (for example Urgent Low).
Verify the sound preview in the settings screen.
Trigger either:
a real glucose low, or
Loop's "next reading as low" test.
Observe the alert sound.
Expected behavior
The glucose alert should use the sound selected in Loop (for example "Urgent Low").
Actual behavior
The notification is delivered as a Critical Alert, but always plays the iOS default Critical Alert sound (Radial).
This occurs for both:
simulated/test glucose alerts
actual glucose low alerts
Additional observations
Critical Alerts are enabled in iOS.
Notifications correctly bypass Silent Mode and Focus.
The selected sound previews correctly inside Loop.
Changing the selected sound has no effect on actual glucose alerts.
Rebuilding from the latest next-dev does not change the behavior.
Investigation
While debugging this locally, I noticed that Libre glucose notifications appear to be generated by:
LibreTransmitter/NotificationHelper.swift
Within NotificationHelper.addRequest(...), critical alerts always assign:
content.sound = .defaultCriticalSound(withAudioVolume: ...)
rather than a named critical sound.
Because of this, it appears that the configured glucose alert sound is never used for Libre glucose alerts.
The notification is correctly marked:
content.interruptionLevel = .critical
but the sound is always assigned via:
.defaultCriticalSound(...)
instead of a user-selected sound.
I wasn't sure if this is intentional while the new Libre alert implementation is under development, or if it's an oversight. I'm happy to test a fix or provide additional information if helpful.
One additional note, while reviewing the code, I also noticed:
Float(criticalVolume / 100)
If criticalVolume is an integer, values between 60–99 would evaluate to 0 before conversion. I'm not sure of the type of mmCriticalAlarmsVolume, so this may or may not be an issue, but it caught my eye during review.
Loop Report 2026-08-01 22_22_25-05_00.md