Add LF Hub by bjorkert · Pull Request #796 · loopandlearn/LoopFollow

bjorkert · 2026-10-27T16:57:17Z

Adds LF Hub, a way to follow a family's push server instead of polling Nightscout or Dexcom from each phone. The hub drives the badge, Live Activity and Speak BG, and alarms are rung as system alarms by a new notification service extension, with a fallback to alarming in the app. Phones join through invites with roles, and LF Hub is offered as the Background Refresh mode right after connecting.

Hub failures are surfaced on Home and in the Ready list: a removed phone leaves at once, rejected pushes and outages are shown, failed source changes can be undone, and snoozes reach the hub before they are marked handled. Fastlane is updated for the new extension target.

…larms rung as system alarms by a notification service extension, and Speak BG, with invites, roles and a fallback to alarming in the app

… a hub

…at once, rejected pushes and outages show on Home and in the Ready list, failed source changes can be undone, snoozes reach the hub before handled, and errors read plainly

codebymini

👍

# Conflicts: # LoopFollow.xcodeproj/project.pbxproj # fastlane/Fastfile

…p the tracked activity on start and end the others, and log system alarm snoozes and handled reports

marionbarker · 2026-10-30T05:01:06Z

Test

This appears to work.
I'm using the hub and token provided for me to test.
I'm not sure what's involved in setting up the hub and whether this will be common.
I'm not sure it should be the first thing that shows up on the Settings screen.
This adds yet another identifier that needs to be documented for the browser build.
I have not test the browser build side of this PR.

… and remind an admin phone every two weeks while a newer hub is out

…the hub is reachable and red while it is not

…ings

… that name the extension

…arm locally until it does, and offer to disconnect

…t with the same Apple Developer account

The body was one long expression: the Form followed by about twenty modifiers, among them four alerts and two confirmation dialogs, each with generic closures and inline Binding(get:set:) values. Swift infers a modifier chain as a single expression, so every added modifier multiplies the work for the type checker. It gave up with "The compiler is unable to type-check this expression in reasonable time" and the build failed. The chain is now three pieces that body puts together: - form: the Form with its task, refresh, notification and sheet modifiers - deviceAlerts(_:): the error, replace, remove and make-member alerts - sourceAndConnectionDialogs(_:): the data-source dialog, the LF Hub mode offer and the disconnect dialog Each piece is checked on its own, which keeps every expression small. Two smaller changes help as well: the data-source dialog's title is worked out beforehand as a typed String, and its action uses if/else instead of a ternary of two awaits. The invite sheet now uses the existing patientDisplayName instead of repeating the same expression. Nothing changes in what the screen shows or does.

marionbarker

Review notes from reading the code (not built or run). The first five are about how hub alarms are adopted and handled.

🤖 Generated with Claude Code

marionbarker · 2026-11-09T20:52:43Z

+            #if !targetEnvironment(macCatalyst)
+                if #available(iOS 26, *) { HubAlarmKit.stop(alarmID: alarmID) }
+            #endif
+            HubClient.shared.alarmHandled(alarmID)


Auto-stop reports a hub alarm as handled. stopAlarm() stops the AlarmKit alarm and POSTs /handled for whatever alarm is current whenever isHubMode. That includes when checkAlarms stops an adopted hub alarm because its condition isn't met locally.

Scenario: Hub mode is on but not confirmed (for example AlarmKit is denied, so drivesAlarms is false while the hub still delivers alarms because settings.alarms = isHubMode). A hub Low alarm arrives as a normal notification and is adopted as currentAlarm. The phone's own data lags the hub's, so the local Low check returns false, which leads to stopAlarm(), then HubAlarmKit.stop and alarmHandled. The hub stops repeating a Low nobody acknowledged.

Suggestion: report /handled only for a user snooze/acknowledge (e.g. from performSnooze), not for every stopAlarm().

Real, though the effect is smaller than described: on the hub, /handled counts as a 2-minute snooze and clears the current alarm, so a Low that still holds fires again after that. It also only happens while the hub isn't driving the alarms, when the phone alarms itself anyway. Fixed: when the local check clears an alarm, the app no longer reports it handled or stops its system alarm; the hub stops that alarm itself once its own check clears it. Snooze, Acknowledge and Snooze All still report as before. (dee1724)

marionbarker · 2026-11-09T20:52:43Z

        // the Live Activity push-to-start uses interruption-level: passive with empty
        // title/body and must not produce a banner or sound when LF is foregrounded.
+        // The hub's badge push is also silent, so only its badge is applied.
        if content.interruptionLevel == .passive || (content.title.isEmpty && content.body.isEmpty) {


Hub system alarms aren't adopted while the app is in the foreground. The NSE sets interruptionLevel = .passive on every hub alarm that rings through AlarmKit, so this early return runs before the lfhubAlarmId adoption below. With the app open, the in-app Snooze/Snoozer doesn't act on the ringing alarm until a later status poll (up to about 60s) adopts it. Consider moving the adoptHubAlarm call above the passive check.

Fixed: the alarm is adopted before the passive check (dee1724). Adoption there only happens while the hub drives the alarms, since the NSE also delivers passively when the phone has left the hub, and those alarms shouldn't be adopted. The system alarm's own Snooze button worked in this case all along.

marionbarker · 2026-11-09T20:52:43Z

+        // them; this app checks the rest. A sound this app started for an alarm the hub
+        // checks stops; the hub's alarm rings instead.
+        var alarms = Storage.shared.alarms.value
+        let hubDrives = HubClient.shared.drivesAlarms


A local alarm can replace the adopted hub alarm. While the hub drives alarms, a local-only alarm type that fires sets currentAlarm to its own id (line 157). That replaces the adopted hub alarm, which is still ringing as a system alarm. Tapping in-app Snooze then snoozes the local alarm and calls alarmHandled for it, so the hub's alarm is never reported handled and keeps repeating.

This can't happen with the current hub: API 1 checks every alarm type the app has, so while the hub drives, the list of alarms checked locally is empty and checkAlarms returns before that line. HubAlarmTypeTests.parity fails if a type is added that the hub doesn't check, which forces this to be handled then.

marionbarker · 2026-11-09T20:52:43Z

+            alarms = HubClient.shared.alarmsCheckedHere(alarms)
+            let soundsHere = Observable.shared.currentAlarm.value.map { id in alarms.contains { $0.id == id } } ?? false
+            if Observable.shared.alarmSoundPlaying.value, !soundsHere {
+                AlarmSound.stop()


currentAlarm stays set after the sound stops. This stops the local sound for an alarm the hub now checks, but currentAlarm and currentAlarmTitleOverride aren't cleared. Because that alarm is now filtered out of alarms, no later tick clears it either. The Snooze UI stays up, and a later snooze sends /handled for an alarm the hub may not be sounding. Consider clearing currentAlarm here too.

Fixed (dee1724), with one adjustment: currentAlarm is cleared only when the hub hasn't adopted that alarm. Clearing it unconditionally would drop an alarm the hub is sounding from the Snoozer until the next status read, and going through stopAlarm() would report it handled.

marionbarker · 2026-11-09T20:52:43Z

+            if Observable.shared.alarmSoundPlaying.value, !soundsHere {
+                AlarmSound.stop()
+            }
+            if alarms.isEmpty { return }


Snooze All is skipped when every alarm is hub-checked. This early return runs before the Snooze All check below. If the user enables Snooze All while an adopted hub alarm rings, stopAlarm() is never called on this phone, and the AlarmKit alarm keeps ringing until the hub gets the uploaded config and sends a stop push (which depends on network and APNs). Consider moving the Snooze All check above this return.

Fixed by moving the Snooze All check above the hub block (dee1724). Online, the hub already handled this: the config upload makes it send a stop push for the sounding alarm. The phone now also stops it locally, which covers the case where the upload or the push fails.

marionbarker · 2026-11-09T20:52:43Z

+        listening = Task { [weak self] in
+            // Coming to the foreground runs a check of its own.
+            var lastCheck = Date()
+            while !Task.isCancelled, let self, self.isActive {


The long poll can't restart after this loop exits. When isActive turns false the loop ends, but listening is never set back to nil, so startListening()'s listening == nil guard blocks every later start. stopListening() is only called from change(to:) and on entering the background, so a mode change from elsewhere (settings/QR import, restore) leaves a finished Task in listening, and the open app stops getting live hub updates. Consider resetting listening = nil when the loop exits on its own.

Leaving this as is. Every way out of Hub mode goes through change(to:), which calls stopListening(), including disconnect. QR import and restore don't touch the background mode. If it ever did happen, the next background/foreground cycle restarts the listener, and alarms don't depend on the long poll. Setting listening = nil at loop exit would also race with a stop and start and could leave two loops running.

marionbarker · 2026-11-09T20:52:43Z

+        }
+    }
+
+    override func serviceExtensionTimeWillExpire() {


Expiry can deliver the content mid-change. serviceExtensionTimeWillExpire delivers the shared content while the Task may still be setting sound / interruptionLevel on another thread. A slow receipt (10s timeout) plus a ringOnce wait of up to 25s can pass the roughly 30s budget. The notification then goes out with its sound and the system alarm also rings, and the concurrent access is a data race on UNMutableNotificationContent. Consider capping the ringOnce wait shorter, or delivering a passive copy on expiry once a ring was scheduled.

Leaving this as is. The receipt and the ring run concurrently (async let), and the ring-once deadline is absolute at 25 s from start, so they don't add up to 35 s. The sound is removed and the content made passive right after AlarmKit schedules the alarm, before the ring-once wait, so expiry during the wait already delivers the passive copy. The only remaining window is AlarmKit's schedule call hanging for about 30 s, where a notification with sound is the right fallback.

marionbarker · 2026-11-09T20:52:43Z

+        // app's own sources.
+        if HubBundle.shared.isActive {
+            Task {
+                if await HubBundle.shared.data(for: .entries) != nil {


Redundant entries lookups (minor). In Hub mode the entries part is looked up here, then again in webLoadNSBGData (hasCurrent) and in NightscoutUtils.load (data(for:)). If the part goes stale between these checks, the tick ends early (Nightscout disabled) or fails with "No current LF Hub data", and that BG update is lost. Consider calling webLoadNSBGData directly and falling back to loadBGFromSources() on failure.

Leaving this as is. The three checks run within milliseconds, so the part has to cross the 3-minute staleness boundary in exactly that gap, and only a follower without a Nightscout URL is affected. The reading is retried within 10–60 s, not lost. Falling back from webLoadNSBGData would change the Dexcom/Nightscout priority and could loop between them.

marionbarker · 2026-11-09T20:52:43Z

+    func render(_ text: String, language: String, completion: @escaping (String?) -> Void) {
+        try? FileManager.default.createDirectory(at: directory, withIntermediateDirectories: true)
+        let old = (try? FileManager.default.contentsOfDirectory(atPath: directory.path)) ?? []
+        for name in old where name.hasPrefix("lfhub-speak-") {


The previous Speak BG sound file can be deleted too early (minor). Every lfhub-speak-* file is deleted before the new one is written, including the file a just-delivered Speak BG notification still points to. If two speak pushes arrive close together, the first announcement can be cut off or fall back to the default sound. Names are also only unique to the second. Consider keeping the last one or two files, or pruning only older ones.

Leaving this as is. The hub sends at most one speak push per new reading, so at least a minute apart, and every speak push has the same apns-collapse-id, so a newer one replaces the older notification anyway. Two speak notifications don't overlap in practice.

…ive hub alarms in the foreground, and check Snooze All before the hub filter

bjorkert added 3 commits October 25, 2026 12:00

Add LF Hub: follow a family's push server for badge, Live Activity, a…

860eaf5

…larms rung as system alarms by a notification service extension, and Speak BG, with invites, roles and a fallback to alarming in the app

Offer LF Hub as the Background Refresh mode right after connecting to…

9409a55

… a hub

Make LF Hub failures visible and recoverable: a removed phone leaves …

161ef4a

…at once, rejected pushes and outages show on Home and in the Ready list, failed source changes can be undone, snoozes reach the hub before handled, and errors read plainly

bjorkert requested review from codebymini and marionbarker as code owners October 27, 2026 16:57

codebymini previously approved these changes Oct 27, 2026

View reviewed changes

Merge remote-tracking branch 'origin/dev' into feature/lfhub

1f36561

# Conflicts: # LoopFollow.xcodeproj/project.pbxproj # fastlane/Fastfile

bjorkert dismissed codebymini’s stale review via 1f36561 October 27, 2026 17:12

bjorkert requested a review from codebymini October 27, 2026 18:50

bjorkert added 3 commits October 28, 2026 08:18

Adopt a push-to-start Live Activity that a refresh already bound, kee…

f8ad6c4

…p the tracked activity on start and end the others, and log system alarm snoozes and handled reports

Clear the alarm title override when the hub stops its alarm

1345a6b

Let the watch fetch on its own while the hub drives the alarms

26cc6f3

bjorkert added 4 commits November 1, 2026 10:52

Show the LF Hub version next to the newest one for the hub's channel,…

5489ca7

… and remind an admin phone every two weeks while a newer hub is out

Show a server icon before the source name in LF Hub mode, blue while …

799386a

…the hub is reachable and red while it is not

Merge remote-tracking branch 'origin/dev' into feature/lfhub

a7c944c

Apply the hub's badge push while LoopFollow is in the foreground

0187fba

bjorkert mentioned this pull request Nov 1, 2026

Loop predictive low alarm uses the full forecast #809

Merged

bjorkert added 3 commits November 2, 2026 10:39

Merge remote-tracking branch 'origin/dev' into feature/lfhub

87e9d14

Drop the removed Download Prediction setting from the hub client sett…

0fd22da

…ings

Merge remote-tracking branch 'origin/dev' into feature/lfhub

e723f84

bjorkert mentioned this pull request Nov 5, 2026

Add the LF Hub identifier steps for dev builders loopandlearn/loopfollowdocs#85

Open

bjorkert and others added 7 commits November 5, 2026 08:31

Link the notification service setup error to the docs

bd5be41

Point the notification service setup error only at App Group failures…

3eed3eb

… that name the extension

Keep the hub connection when the hub does not recognize the phone, al…

01286fa

…arm locally until it does, and offer to disconnect

Drop the hub heartbeat log

67804f2

Show LF Hub as the last row under Data Settings

fc6a44f

Explain that an admin's shared APN key works only for LoopFollow buil…

3f6a7dd

…t with the same Apple Developer account

marionbarker reviewed Nov 9, 2026

View reviewed changes

Report hub alarms handled only when the user handles them, adopt pass…

dee1724

…ive hub alarms in the foreground, and check Snooze All before the hub filter

Conversation

bjorkert commented Oct 27, 2026

Uh oh!

codebymini left a comment

Choose a reason for hiding this comment

Uh oh!

marionbarker commented Oct 30, 2026

Test

Uh oh!

marionbarker left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants