Filter devices based on must have feature

I'm still a little unsure on how to approach if I want to write a watchface for devices that MUST have a desired feature.

In my case I want to only support devices that do support following:

  • Vector Font which means API level must be 4.2.1 or higher
  • OnDeviceSettings which means API level must be 2.4.0 or higher

When I now want to determine which devices do support those features by 100% (no matter if they have outdated firmwares or if they are asian or european based) how do I continue now? If my watchface can be installed I must be sure that it supports the features I need.

I think I must find out which devices have been released with API level 4.2.1 or higher on their first release, correct? Can I just say, that the most restricting feature are the vector fonts so I just check which devices do support vector fonts and check  the list of supported devices there:

https://developer.garmin.com/connect-iq/api-docs/Toybox/Graphics/VectorFont.html

I can simply use the list of supported devices from the vector font supported devices list, but how do I continue now? Is that all or must I somehow make sure that even the first version of a device was already supporting vector font by making sure, that the watch was released with API 4.2.1 or higher?

My goal is that my watchface can only be installed on devices with API 4.2.1 or higher that do support vector fonts for sure (so I do not need to check for vector font support via :has)

Question:

  • is checking the supported devices list of a feature enough for my use case?
  • is this logic true for any feature?

Top Replies

  • store will make sure that device has the firmware / CIQ specified for a given part number

    This is all I needed to know. I don't care if there may exist devices that can't install my watchface…

All Replies

  • store will make sure that device has the firmware / CIQ specified for a given part number

    This is all I needed to know. I don't care if there may exist devices that can't install my watchface even if the device is listed as supported device in the store. If the user is informed that he must install a newer firmware if he wants to install it, that's fine. As long as I can be sure that the desired functionality is available on all devices on which my watchface is installed on.

    I appreciate all the details in your answers and though.

    My use case is following and that's why I asked the question:

    I have a watchface with a lot of customisation options and custom fonts for rotated letters - this means my watchface does really hit the memory limits on some devices already and I can't add any new feature anymore.

    So I will offer a new version of my watchface for newer devices that uses vector fonts and on device settings so that people owning such a device can upgrade to the new watchface and enjoy all the benefits including all the new customisation options I will offer and easy access to them from on device.

    People with older devices (or newer devices with older firmware) can still use the old version. That's why I do not want to use runtime checks and really wanted to make the distinction before installing a watchface.

  • I don't care if there may exist devices that can't install my watchface even if the device is listed as supported device in the store. If the user is informed that he must install a newer firmware if he wants to install it, that's fine. As long as I can be sure that the desired functionality is available on all devices on which my watchface is installed on.

    That’s what I guessed when you said “If my watchface can be installed I must be sure that it supports the features I need”, but thank you for clarifying. 

    There isn’t really much else Garmin could do otherwise to gatekeep supported devices which have old firmware, if you think about it. Garmin still wants those users to see apps which require a firmware update — they wouldn’t want users with older firmware to see fewer store search results than users with newer firmware. Garmin probably wouldn’t want to distinguish those search results in any way either, bc that would only be confusing.

    Besides, it’s been the case for a while that users are expected to update apps / firmware / OSs regularly, especially to receive security updates. Auto-update has been on by default everywhere for a long time.

    My use case is following and that's why I asked the question:

    I have a watchface with a lot of customisation options and custom fonts for rotated letters - this means my watchface does really hit the memory limits on some devices already and I can't add any new feature anymore.

    So I will offer a new version of my watchface for newer devices that uses vector fonts and on device settings so that people owning such a device can upgrade to the new watchface and enjoy all the benefits including all the new customisation options I will offer and easy access to them from on device.

    People with older devices (or newer devices with older firmware) can still use the old version.

    Thanks for clarifying! By “new version” do you mean a completely new app in the store? Or do you mean a new version of an existing app?

    So one place where Garmin could do more is something Apple does (last I checked) — if you have an Apple device with an old iOS system software version and you want to download an app which only supports a newer iOS, then Apple allows you to download the latest version of the app that supports your iOS. Garmin doesn’t.

    I’ve personally taken the approach of maintaining two “versions” of a certain app in the store as distinct apps — a “classic” version with less features (that will never again be updated, unless there’s major bug), and an updated version with more features that’s constantly updated. Not sure if it was worth the effort, but I didn’t want to screw any older users over. (My app is unique in that the amount of memory it takes up is highly dependent on the user’s use case for the app.)

  • I think by not deprecating a watchface too early I can be quite sure that people with outdated  or incompatible firmware are very few.

    By “new version” do you mean a completely new app in the store? Or do you mean a new version of an existing app?

    The decision is not yet made, if I can manage to set up everything with only minimal impact on the old version I probably will just release a new version, otherwise I'll release a v3 of my app (did already abondan a version in the past when garmin added weather because I wanted to get rid of the internet and background processing permission for more "security"... and because I did (and do) use a google cloud app to parse the OWM weather json and returning a minimized response because the OWM json response was too large for the memory constraints of my watchface - sadly the cloud script is not cost free and has limits that's why I wanted to limit the number of devices that need to use it).


    So far my question is fully answered, thank you.