Improvements to critical alarm handling by ETolboom · Pull Request #38 · LoopKit/LibreTransmitter

ETolboom · 2026-04-21T23:45:41Z

This commit adds several improvements to the current handling of critical alerts:

A "Do Not Disturb" override toggle has been added to each individual schedule.
A banner for requesting critical alert permissions is shown if shouldOverrideDoNotDisturb is explictly set to true by the user in NotificationHelperOverride
Critical Alert Volume has been moved from its own sub-menu into the Alarm Settings view

Disclaimer: I have made use of A.I. in order to implement this feature as I am not primarily a Swift developer (primarily Golang). I have critically reviewed every line of code to ensure that the solution is minimal and correct.

I've also ensured that everything related to settings and state is handled in NotifcationHelper and nothing is mutated from the UI side.

I was unsure how to approach Localization as I see Lokalise is used.

Screenshots in app

Add Do Not Disturb override toggle to each schedule Add banner for requesting critical alert permissions if shouldOverrideDoNotDisturb is true Move Critical Alert Volume into Alarm Settings view

Copilot

Pull request overview

This PR refactors and extends “critical alert” support by moving the critical volume control into Alarm Settings, adding a per-schedule Do Not Disturb override, and introducing a permission-request banner (gated by NotificationHelperOverride).

Changes:

Add per-schedule overrideDoNotDisturb and propagate it through persistence/state.
Add a Critical Alerts permission banner + request flow, and a conditional critical volume section in Alarm Settings.
Update notification sending so glucose alarms are only “critical” when the active schedule requests DND override.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
LibreTransmitterUI/Views/Settings/SettingsView.swift	Removes the standalone navigation entry for critical volume (moving it into Alarm Settings).
LibreTransmitterUI/Views/Settings/AlarmSettings/CriticalAlarmsVolumeView.swift	Replaces the old view with reusable sections: permission banner + critical volume slider section.
LibreTransmitterUI/Views/Settings/AlarmSettings/AlarmSettingsView.swift	Adds schedule-level DND override UI/state and conditionally shows the critical volume section.
LibreTransmitter/NotificationHelperOverride.swift	Exposes override flag publicly for UI usage.
LibreTransmitter/NotificationHelper.swift	Adds critical-alert permission/status helpers; makes glucose notifications critical only when schedule override is enabled.
Common/Settings/GlucoseSchedules.swift	Adds persisted `overrideDoNotDisturb` to schedules and logic to determine when it should apply.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-21T23:51:41Z

                    AlarmHighRow(schedule: schedule, glucoseUnit: glucoseUnit, glucoseUnitDesc: glucoseUnitDesc, errorReporter: errorReporter)
+                    if criticalAlertsEnabled {
+                        OverrideDoNotDisturbRow(schedule: schedule)
+                    }


The per-schedule "Override Do Not Disturb" toggle is only rendered when criticalAlertsEnabled is true. This means users can’t preconfigure overrides before enabling the permission (and it also partially contradicts the PR description that the toggle is added to each schedule). Consider always showing the row but disabling it (or showing explanatory text) when Critical Alerts aren’t enabled.

I personally think this is still proper.

If the user does not have the permission, the toggles nor the volume slider have any effect. Only after the user has set shouldOverrideDoNotDisturb to true and given critical alert permissions should the functionality be available.

"Override Do Not Disturb" might be confusing to have enabled on a per schedule basis, it should ideally be set for all schedules at once. I might be misunderstanding the intention or use-case though. My intention is that a user will rather use the "silence/snooze" feature for situations where no audible alarms are required.

"Override Do Not Disturb" might be confusing to have enabled on a per schedule basis, it should ideally be set for all schedules at once. I might be misunderstanding the intention or use-case though. My intention is that a user will rather use the "silence/snooze" feature for situations where no audible alarms are required.

Hi,

I had envisioned it like this:
Schedule 1 and schedule 2 would represent day time and night time schedules, respectively.

Schedule 1 will present HIGH and LOW alarms as a normal notification.

Schedule 2 will present the same but then with audible alarms through the use of critical alerts.

My reasoning was that for overnight lows its critical I hear them. Critical alerts allow a minimum volume and can bypass any focus profiles. During the day I'm usually on my phone enough (or apple watch) such that the notifications will tell me enough. Furthemore, I often have classes and meetings during the day so that requires my phone to be on silent.

Copilot · 2026-04-21T23:51:42Z

    }

+    public static func requestCriticalAlertPermission(completion: @escaping (Bool) -> Void) {
+        UNUserNotificationCenter.current().requestAuthorization(options: [.badge, .sound, .alert, .criticalAlert]) { _, _ in


requestCriticalAlertPermission discards the granted and error values returned by requestAuthorization. Using those values would allow the UI to show a more accurate message (e.g. denied vs. missing entitlement) and avoid an extra round-trip in some cases.

Suggested change

UNUserNotificationCenter.current().requestAuthorization(options: [.badge, .sound, .alert, .criticalAlert]) { _, _ in

UNUserNotificationCenter.current().requestAuthorization(options: [.badge, .sound, .alert, .criticalAlert]) { granted, error in

if let error {

logger.debug("\(#function) failed to request critical alert permission: \(error.localizedDescription)")

criticalAlarmsEnabled = false

DispatchQueue.main.async {

completion(false)

}

return

}

guard granted else {

logger.debug("\(#function) critical alert permission denied")

criticalAlarmsEnabled = false

DispatchQueue.main.async {

completion(false)

}

return

}

I don't think this is meaningful.

requestCriticalAlertPermission is called from the CriticalAlertsBannerSection which already shows a proper message in case the result is not .enabled

If the user denied it then it is clear what the reason is. Otherwise there is only possible reason left: the app was not built with the correct entitlements.

ETolboom · 2026-04-21T23:56:12Z

Will review the Copilot suggestions tomorrow

…VolumeView.swift Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

…calAlertsBannerSection) into AlarmSettingsView

…dules changes not being detected Always show volume section if critical alerts permission been granted

Improvements to critical alarm handling

d7e3385

Add Do Not Disturb override toggle to each schedule Add banner for requesting critical alert permissions if shouldOverrideDoNotDisturb is true Move Critical Alert Volume into Alarm Settings view

Copilot AI review requested due to automatic review settings April 21, 2026 23:45

Copilot started reviewing on behalf of ETolboom April 21, 2026 23:46 View session

Copilot AI reviewed Apr 21, 2026

View reviewed changes

ETolboom and others added 5 commits April 22, 2026 10:58

Update LibreTransmitterUI/Views/Settings/AlarmSettings/CriticalAlarms…

f2bc27f

…VolumeView.swift Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Update LibreTransmitter/NotificationHelperOverride.swift

5d4622b

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Add LocalizedString

a3e03d7

Merge CriticalAlarmsVolumeView (CriticalAlarmsVolumeSection and Criti…

69aec75

…calAlertsBannerSection) into AlarmSettingsView

Avoid CriticalAlarmsVolumeSection from not being rendered due to sche…

dfe5ec8

…dules changes not being detected Always show volume section if critical alerts permission been granted

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improvements to critical alarm handling#38

Improvements to critical alarm handling#38
ETolboom wants to merge 6 commits intoLoopKit:mainfrom
ETolboom:improved-critical-alerts

ETolboom commented Apr 21, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI Apr 21, 2026

Uh oh!

ETolboom Apr 22, 2026

Uh oh!

dabear Apr 23, 2026

Uh oh!

ETolboom Apr 24, 2026

Uh oh!

Copilot AI Apr 21, 2026

Uh oh!

ETolboom Apr 22, 2026

Uh oh!

Uh oh!

ETolboom commented Apr 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

-        UNUserNotificationCenter.current().requestAuthorization(options: [.badge, .sound, .alert, .criticalAlert]) { _, _ in
+        UNUserNotificationCenter.current().requestAuthorization(options: [.badge, .sound, .alert, .criticalAlert]) { granted, error in
+            if let error {
+                logger.debug("\(#function) failed to request critical alert permission: \(error.localizedDescription)")
+                criticalAlarmsEnabled = false
+                DispatchQueue.main.async {
+                    completion(false)
+                }
+                return
+            }
+            guard granted else {
+                logger.debug("\(#function) critical alert permission denied")
+                criticalAlarmsEnabled = false
+                DispatchQueue.main.async {
+                    completion(false)
+                }
+                return
+            }

Conversation

ETolboom commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

ETolboom Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

dabear Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

ETolboom Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

ETolboom Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ETolboom commented Apr 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ETolboom commented Apr 21, 2026 •

edited

Loading