Got Loop updated, then iOS, now working in Watch update. Loop And CGM are working again. 4:45am.
6 Likes
Mine pestered me for about 48 hours. I haven’t seen it so far today.
2 Likes
I’m now getting a pop up pushing 15 day sensor.
2 Likes
I was getting that message, too, even though I don’t use an apple watch. However, I did see the watch app in the app library and immediately deleted it. That message has not popped up again.
4 Likes
I know it’s annoying, but it’s also kinda hilarious.
Eric, your truck needs a new transmission.
Uh…I don’t have a truck.
Like I said in the title - Dexcom is absolutely maddening!
6 Likes
Because the actual upgrade is a moving, and unknown, target, but their need to release a new version of the app forces them to make a date (apparently Jan 6) when they will drop the new release of the app into the AppStore.
An app developer is forced to rebuild the app at some point because the OS developer (Apple or Google) comes up with a new version of the OS which will not work with the current version of the app.
Yes, clearly there are ways round this but only if the AppStore supports them fully; Dexcom could release multiple versions of their app and the AppStore could select the right one based on the current OS. The problem with that is that if the Apple OS then got upgraded the installed Dexcom app would stop working unless Apple also supported automatic upgrade of all the affected installed apps, or maybe just Dexcom’s.
I don’t know what options are available to Apple app developers. I did get an Apple Developer license but I never used it because it seemed like I’d open that door and be in a maze of twisty passages all alike.
I do somewhat know the Android choices and they are certainly equivalent:
- I can’t build AAPS for a lower Android version than that supported by the AAPS source code.
- I have to choose a target OS version. I believe this is the lower limit of where it will install.
It seems that both AAPS and xDrip+ choose to build for the current version of the OS (a moving target) and a lowest version defined by that or, for AAPS, a higher version that suits the developers. In both cases there are lowest supported versions and they do go up, not down.
I can’t directly compare the AAPS or xDrip+ lowest OS compatibility with Apple because although the version numbers are similar they are not the same. However it is certainly true that changes often have to be made to support the latest-greatest-tightest-OS and an app will not run if those changes are not made.
This is the way the app world is, but I can’t know whether Dexcom chose to drop support for iOS 18.5.999999 because they were just finding it too difficult or because they felt they had to support iOS 26.3, based on possibly secret information they had received under an NDA, etc. Indeed, I can’t even know if they just did it to take a quick hit on the stock price:
But based on what I do know what they have done (dropping support <18.6) is something that sooner or later they would have had to do.
That is not the way it works. iPhone doesn’t broadcast data to apps. Apps are independently receiving signals from Dexcom. When I calibrate Dexcom and tandem, sometimes values are different. If you look in settings/Bluetooth there is only an active connection from tandem to iPhone. The apps seem to handle to Bluetooth independently. I never have a problem with Dexcom/Dexcom app. I constantly have disconnects between tandem/tandem app. Bluetooth implementation on tandem is poor. Might be the antenna or medal case. The experiment would be to delete the Dexcom app and see what happens.
The “fix” for new iOS releases is to turn off automatic updates. I have not had problems but once in memory where tandem didn’t implement their changes in time for the new release.
Cheers
4 Likes
It works in the way I described. The actual readings sent out by the G7 are “unsmoothed”, which means they are sometimes all over the place. The results send by the t:slim or, for that matter, displayed by the Dexcom receiver or the Dexcom app, are “smoothed”, the last few readings have been averaged together to remove the bumps.
xDrip+ allows the “unsmoothed” readings, the raw ones sent out by the G7, to be seen. (BTW the G6 was very different). Because the smoothing happens in the individual app or the t:slim the same reading can end up being “smoothed” to different reported values. Indeed AAPS supports several different smoothing algorithms.
What you describe would require more than one reading every 5 minutes. I verified earlier today, when my G7 failed early, that the G7 is behaving consistently with what I said. I connected xDrip+ to the new sensor then connected the Dexcom receiver and I could see that the both xDrip+ and the Dexcom receiver started their communications without a second or so of each other. So I could see the receiver setting up the “pairing” just as xDrip+ was connecting for a new reading.
I do agree that removing xDrip+ or the Dexcom app (only one can be used at once) from the environment would be a useful experiment; I suggested removing the app earlier but it occurs to me that simply turning the 'phone off for a while is the same experiment.
Disabling new iOS releases is maybe a worse solution although I and others have suggested this in the past. I believe this is what @eric had done hence the “forced upgrade”. Turning off the auto-upgrade implies doing a manual upgrade on a regular basis (every couple of years maybe) to avoid dropped support.
When I first got Dexcom G6 7 years ago it was recommended to turn auto updates off. At that time Dexcom would email iirc a notice that it was OK to update. For some reason they have stopped doing the notification. I will check with both Dexcom and Tandem.
1 Like