[dnzxy]

Followers can no longer be listed, invited or removed from the app. The legacy Share endpoints behind this can leave followers of the Dexcom app without updates. Followers set up through the Dexcom app are unaffected.

Upload now posts readings first, and only signs in again, starts a monitoring session or registers the sensor as the account's device when the service refuses for that reason. This also stops uploads stalling after a sensor change until the app is relaunched.

Notes

• Once a serial is registered, it isn't registered again until a relaunch or a new sign-in. This is deliberate: if the Dexcom app takes the account's device back, Loop lets it instead of taking turns with it.
• For the release notes: followers invited from Loop keep working, but they can now only be seen or removed in the Dexcom app.

[ps2]

Posting first and only recovering on the matching refusal looks good. It also fixes the sensor-change stall: G7CGMManager sets the new serial on the existing uploader, so the first MonitoredReceiverNotAssigned / SerialNumberDoesNotMatch registers the new sensor. The stubbed upload-flow tests are nice. All 176 G7SensorKit tests pass here (simulator, not tried against a real account).

A few things:

1. A refusal from a recovery isn't itself recovered. In upload(_:serial:), if perform(recovery) throws, the upload fails right away. Take a new sensor or a fresh account: the post is refused with MonitoringSessionNotActive, and StartRemoteMonitoringSession could then be refused because the receiver isn't assigned yet. The upload backs off 15 minutes and repeats the same sequence each time. It never calls ReplacePublisherAccountMonitoredReceiver, so uploads stop for good. The old code always assigned first, so it couldn't hit this. The tests only cover the receiver-refused-first order. Could the error thrown by perform go back through recovery(for:) too, keeping the once-per-recovery limit?

2. assignedSerial is never cleared. If something else, e.g. the Dexcom app on another phone, takes the monitored receiver while the same sensor is in use, Loop won't register it again until relaunch or a sensor change. The settings screen shows an upload error meanwhile. If that's deliberate, so Loop doesn't fight the Dexcom app, a line in the description would help. If not, clearing it after a successful post would allow one re-registration per takeover.

3. Followers already invited from Loop keep working, but they can only be seen or removed in the Dexcom app now. That's probably worth a note when this ships.

Minor: the removed follower strings are still in both Localizable.xcstrings files and will show as stale on the next export.

[dnzxy]

Thanks Pete!

1. Good catch, fixed in da3477d. If a recovery step is refused, that refusal now goes through the same recovery too, so a refused StartRemoteMonitoringSession leads to registering the sensor, then a fresh monitoring start and the post. Each step still runs once per attempt, except that a new registration allows one more monitoring start. Added a test for exactly your order.
2. Deliberate. If we cleared it after each successful post, Loop and a Dexcom app on another phone would keep taking the device from each other on every reading. That's also the kind of repeated legacy-API write we want to avoid. A new sign-in or a relaunch registers again, and the settings screen shows the upload error until then. Added a comment and a test that pin this down.
3. Agreed, we'll call it out in the release notes: followers invited from Loop keep working, but from now on they can only be seen or removed in the Dexcom app.

On the strings: the committed xcstrings on next-dev never contained the follower strings. I think what you saw was Xcode syncing them locally during a build.

Tested against current next-dev: all 184 G7SensorKit tests pass.

[ps2]

Thanks!