Acknowledged
6 months ago

Given that a newer SDK is required to build for CIQ 5.x devices, what does this mean for existing apps on devices that were upgraded from CIQ 4 to CIQ 5 (e.g. FR955, Fenix 7, etc)? Do these apps just break?

Background:

- it has always by my understanding that if you build an app for a device with a given SDK, then that app should continue to work regardless of future firmware updates (in general). This ofc excludes situations where:

  - the new firmware update has a bug or breaking change

  - the existing app has a dormant bug which is exposed by a legit change in new firmware. e.g. newer firmware has a change where Weather.CurrentConditions.observationLocationName is null, and this caused several existing watchfaces to crash because they assume that field will never be null. But that's an application error, since that field has always been typed to be possibly null

- CIQ 5.* devices require various 7.X (or 8.X) SDKs to run properly

- Compilers have a check to ensure you don't try to build a a too-new device with a too-old device

- Due to a bug in this check, where older compilers (pre 7.2.0) seem to incorrectly believe that SDK version X can build any device with CIQ version X (or lower), it's possible for an SDK 6.X compiler to build an app for CIQ 5 devices. However, it's very possible that such an app will crash when it's run in the simulator or the device (we've already seen "bug reports" about this

- The existing crop of devices that came out with CIQ 4 (e.g. fr955, fr965, fenix7) have all been updated to CIQ 5. As far as I know, this is the first time that existing devices have received a major CIQ update since the move from CIQ 1 to CIQ 2.

- Someone in the CIQ team already clarified that CIQ 5 devices require apps to be built with newer SDKs.

So here's what I don't understand.

The two following statements seem to be mutually exclusive:

- If an app is built for a device with an existing SDK (e.g. SDK 6.4.0) it will continue (in general) to work on the device for all future firmware updates

- Devices with CIQ 5.* require a 7.X or 8.X SDK

The problem is that it was entirely possible to build an app for an fr955 (for example) with SDK 6.4.0 in the past, when fr955 was only on CIQ 4. If I installed such an app on my fr955 when it had CIQ 4, it would expect it to continue to work now that my device is on CIQ 5.

So how can it be possible that going forward, a 7.X or 8.X SDK is required to build for my fr955?

What am I missing? Has something also changed with the device files that's relevant here?

flowstate
Parents
  • 7 months ago

    Regarding deprecation:

    - I have the impression that *in general*, deprecation was usually something applied "in the future" to new (not yet existing) devices, with new (not yet existing) major CIQ versions.

    Ofc there are exceptions, like Weather.currentConditions.observationLocationName, which has been deprecated in a recent SDK update. I know that the field isn't actually removed on the devices (yet), but it's set to null. I kinda wonder what the value would be for actually removing the field, except to definitively break any app that still uses it, even with the correct null check. Does Garmin really wanna do that? Isn't it bad enough that badly-written apps broke bc they don't have a null check (which is def a bug, since the field was always typed to be possible null)

    - for example, Application.loadProperties/saveProperties were scheduled for deprecation "after System 4" (which is CIQ 3.2/CIQ 4). To me this is ok because the only devices which require those functions were CIQ 2 devices, and CIQ 2 devices would never get CIQ 3

    - Yes, even this situation has an obvious problem for devs. If someone chose to use loadProperties/saveProperties in System 4 (or CIQ 3.0.x to CIQ 3.1.x), they could reasonably expect their code to stop working if Garmin kept their promise and removed those functions after System 4.

    - If that happened, Garmin could reasonably turn around and say "I told you so".

    - *However*, at least a couple of years ago (long after the original deprecation announcement, Garmin had still held back on removing loadProperties/saveProperties because devs were still using it. A CIQ team member (Travis) expressed frustration in a comment on a bug report that devs were still using these functions, bc the team wants to get rid of them. I don't know if they've finally done so.

    So ironically, the deprecation argument actually provides evidence that Garmin doesn't want apps to automatically break with firmware updates.

    > Ideally Garmin should never deprecate anything "too fast", meaning that they should announce that something is going to be deprecated in a way that any developer not aware before the announcement could release an app available on all devices and not having to check each and every method with runtime has check.

    If Garmin has to be cautious about deprecating things (as you said and as with my argument above), isn't deprecation sort of the exception that proves the general rule that new firmware should be backwards compatible with old apps?

    Exhibit B: auto-migration. If it was the case that old apps are supposed to "automatically break" with new firmware (or new devices), then Garmin would have never implemented auto-migration. The existence of auto-migration implies that in fact, in some cases, old apps should be able to run on new devices, with 0 code changes.

    Then again, idk if any of my apps have been auto-migrated in the past few years. Certainly I can't imagine a CIQ 4 app being auto-migrated to a CIQ 5 devices (or can I?)

    Anyway, I think the huge difference in the current era, which I have alluded to a couple of times, is that all the CIQ 4 devices got CIQ 5. A new major version seems to imply breaking changes in a way that a new minor version does not.

    Contrast with the past, when no CIQ 3 device was ever upgraded to CIQ 4, and no CIQ 2 device ever got CIQ 3. Yes, many CIQ 1.x devices got CIQ 2.x, but at the time the ecosystem was so new we probably didn't care so much. And I don't think that apps built with a CIQ 1.* SDK ever broke because a device was updated to CIQ 2, so there is that, as well.

    Anyway, I have an 8 year old running pace calculator on my iPhone with a recent iOS. Yes, Apple breaks backwards compatibility all the time (e.g. removing support for 32-bit apps), but even they have a *general* strategy of not "automatically" breaking apps with a firmware/OS update.

Comment
  • 7 months ago

    Regarding deprecation:

    - I have the impression that *in general*, deprecation was usually something applied "in the future" to new (not yet existing) devices, with new (not yet existing) major CIQ versions.

    Ofc there are exceptions, like Weather.currentConditions.observationLocationName, which has been deprecated in a recent SDK update. I know that the field isn't actually removed on the devices (yet), but it's set to null. I kinda wonder what the value would be for actually removing the field, except to definitively break any app that still uses it, even with the correct null check. Does Garmin really wanna do that? Isn't it bad enough that badly-written apps broke bc they don't have a null check (which is def a bug, since the field was always typed to be possible null)

    - for example, Application.loadProperties/saveProperties were scheduled for deprecation "after System 4" (which is CIQ 3.2/CIQ 4). To me this is ok because the only devices which require those functions were CIQ 2 devices, and CIQ 2 devices would never get CIQ 3

    - Yes, even this situation has an obvious problem for devs. If someone chose to use loadProperties/saveProperties in System 4 (or CIQ 3.0.x to CIQ 3.1.x), they could reasonably expect their code to stop working if Garmin kept their promise and removed those functions after System 4.

    - If that happened, Garmin could reasonably turn around and say "I told you so".

    - *However*, at least a couple of years ago (long after the original deprecation announcement, Garmin had still held back on removing loadProperties/saveProperties because devs were still using it. A CIQ team member (Travis) expressed frustration in a comment on a bug report that devs were still using these functions, bc the team wants to get rid of them. I don't know if they've finally done so.

    So ironically, the deprecation argument actually provides evidence that Garmin doesn't want apps to automatically break with firmware updates.

    > Ideally Garmin should never deprecate anything "too fast", meaning that they should announce that something is going to be deprecated in a way that any developer not aware before the announcement could release an app available on all devices and not having to check each and every method with runtime has check.

    If Garmin has to be cautious about deprecating things (as you said and as with my argument above), isn't deprecation sort of the exception that proves the general rule that new firmware should be backwards compatible with old apps?

    Exhibit B: auto-migration. If it was the case that old apps are supposed to "automatically break" with new firmware (or new devices), then Garmin would have never implemented auto-migration. The existence of auto-migration implies that in fact, in some cases, old apps should be able to run on new devices, with 0 code changes.

    Then again, idk if any of my apps have been auto-migrated in the past few years. Certainly I can't imagine a CIQ 4 app being auto-migrated to a CIQ 5 devices (or can I?)

    Anyway, I think the huge difference in the current era, which I have alluded to a couple of times, is that all the CIQ 4 devices got CIQ 5. A new major version seems to imply breaking changes in a way that a new minor version does not.

    Contrast with the past, when no CIQ 3 device was ever upgraded to CIQ 4, and no CIQ 2 device ever got CIQ 3. Yes, many CIQ 1.x devices got CIQ 2.x, but at the time the ecosystem was so new we probably didn't care so much. And I don't think that apps built with a CIQ 1.* SDK ever broke because a device was updated to CIQ 2, so there is that, as well.

    Anyway, I have an 8 year old running pace calculator on my iPhone with a recent iOS. Yes, Apple breaks backwards compatibility all the time (e.g. removing support for 32-bit apps), but even they have a *general* strategy of not "automatically" breaking apps with a firmware/OS update.

Children
No Data