Devices removed from manifest - can still search and install the app

I never tried it, but thought about it many times and you're now confirming that it works as I thought:

V1 supported old, new device

V2 only supports new

But old device still sees the latest compatible version: V1

Now I think there's still some unknown that would need some testing:

Does an old device belonging to a user who never installed the app earlier see it and able to install it, or only users who had it installed in the past?

For me while testing on Vivoactive3 and android device there is no issue - only one app is visible except the case you mention when user had installed the app prior split he will still have it, old version from the time his device was supported with no ability yo update (there  is a message that device is not supported anymore). Number of such users will drop over time.

I think this behavior is most common since It was reported to me couple of times by users (I had to let them know that they need to switch over to the app that supports old device). I can live with this, it cost me not a lot to explain to users that they need to switch over to another app.

The other behavior I described above was different. It was new user asking me which of those two apps he shall use as both can be installed, both looks identical except one of them installs with earlier version than shown in the store (the last version with support for Forerunner 245). It can give me a hard time when it comes to providing license to the users once they realize they shall switch over to app that will get updates for their device especially for those who use iOS (garmin connect does not run in background hence app cannot download license from my server unless user keep GC on while using my app - a nightmare at the moment as I haven't implemented any prompts to instruct the users by my app).

So maybe all users see the most recent version that supports their device. Probably the only way to prevent it is to release a newer version (v3) that for old device doesn't do anything but display a message that directs them to the other app (you can open the url of the other app in the store, IMHO it'll tell the user to open it on the phone, which will open it in Connect IQ

I see your point, can be done :) except would love to get to know the list of devices that behaves this way, like Fr245 and introduce such trick on one go.

Wow great find SzymonP!

flocsy🤠 said:

So maybe all users see the most recent version that supports their device

This is actually how I always hoped it worked haha.

I think the Apple app store works this way, although the ability to offer old versions seems to be left at the developer's discretion: discussions.apple.com/.../8090150

SzymonP said:

The problem is that one of my users (Forerunner 245) reported to me that he sees both apps

Yeah you can confirm this using the CIQ store link for fr245 - [https://apps.garmin.com/devices/forerunner245/apps] (*) - and searching for "tennis ai". Both apps show up, although the link to v1 isn't anything special - clicking on that link still shows an app page which claims there's no support for fr245. [The internal "app info" API doesn't seem to have any reference to fr245 or old versions, either.] [**]

(*) here's how to figure out the CIQ store link for any given device / part number: https://forums.garmin.com/developer/connect-iq/f/discussion/382457/ciq-store-website-links-for-new-devices-fenix-8-e-enduro-3-instinct-3-e

[**] use the deviceTypes API request to correlate "device type IDs" and "part numbers" in the "app info API" response to actual devices (in some cases, this API gives you info about part numbers that's not available in compiler.json, such as which of the fenix7x's 4 part numbers corresponds to which actual devices (such as "Fenix 7X" and "Tactix 7X"):

[https://apps.garmin.com/api/appsLibraryExternalServices/api/asw/deviceTypes]

So whatever info the Connect IQ app or website is using to display / install your v1 app for fr245 doesn't seem to be available to us [at least in the browser].

I wonder if the download button will be enabled in the *browser* for a user who only has an fr245? Or if they would actually see a different page than I would, when logged in. [I don't own an fr245.]

If I were you, I would the ask your user if they can:

- press the download button in the first app’s (0073…) website (assuming they're willing to uninstall the app, if it's currently installed)

- take screenshots of the first app’s website's supported device list or tell you whether Forerunner 245 is actually on the list

- send you the raw data from the app info API (opened in the browser where they're also logged into the Connect IQ website): https://apps.garmin.com/api/appsLibraryExternalServices/api/asw/apps/0073ddf4-3ec7-436d-a598-d88cfd0d583a

That's probably too much to ask though.

You could maybe just do the same experiment with an app of your own (it could even be a beta app, assuming you don't want to test the part about searching for the app after opening the device-specific search page.)

I kinda wanna do this now.

SzymonP said:

I see your point, can be done :) except would love to get to know the list of devices that behaves this way, like Fr245 and introduce such trick on one go.

Hypothetically you could release an app that isn't intended to be downloaded [making sure to emphasize that it the title and description] that supports all devices, and making sure to use a title that's easily searchable.

Then you could release a version which has support for no devices [or maybe only 1 device, if 0 devices is not allowed]. For each of the device-specific store links, you could search for the app and see if it still appears.

Yeah, that would be a huge pain as there's 153 "CIQ devices" and 298 part numbers. You could also try to automate this process [perhaps using the URL of the unique listing image for your app to programatically find it in the results]

Not sure I understand. If I understand correctly then this is independent from the devices. All the devices that were in V1 and are not in V2 will behave the same way, because that "behaviour" is in the store, not in the device. So you already do know the list, cause you created it by removing devices.

If you want to be on the safe side,you can create 2 consecutive builds and upload them immediately one after the other. The risk that someone downloads the 1st build on a new device within that 1 minute (*) window is very small.

So you create a version strip of all the functionality that just redirects everyone to the new app in the store ,(this will be v3), and a version that is identical to V2 (this will be V4)

Then you upload v3, and immediately after it V4.

*) there is a slight chance that something happens in the backend of the store, and they'll process v3, but not V4 (not immediately), then all users will get the strip down version until Garmin fixes the store. If you do trust yourself on knowing which devices you removed between V1 and V2, then only strip the functionality and redirect to the new app for those devices. Then you only need one version.

flocsy🤠 said:

Not sure I understand. If I understand correctly then this is independent from the devices. All the devices that were in V1 and are not in V2 will behave the same way, because that "behaviour" is in the store, not in the device. So you already do know the list, cause you created it by removing devices.

I think SzymonP is saying that we don’t know whether the behaviour is independent of the device. I mean it probably is, but what if it isn’t? Maybe for some weird reason, this only works with CIQ 3+ devices, for example.

That’s why I suggested that the device-specific CIQ store website links can be used to try to verify which devices support this behavior.

For example, the first app (0073…) lost support for several old devices. To try to verify that each of those old devices can still access the app, they could try using the device-specific store website links and see if the first app shows up in a search.

That won’t prove anything definitively (they wouldn’t be sure if those devices can actually install the app even if it shows up), but it would be strong evidence.

And again, a dev could try to an experiment that tests *all* the device/part numbers with a single test app (or at least all but one device, assuming that an app needs to support at least one device.) With two test apps, a dev could conceivably cover all the device/part numbers.

Or Garmin could just tell us how this works. I think this is pretty intriguing behavior (it’s something I asked for before, but now I wonder if the store always worked this way?)

Than you a lot for a suggestion to double check the device support using device-dedicated link. I will, for sure, do so to get to know which devices can face the issue described. It will ease to investigate any issues users are reporting to me. At this moment those cases are too rare to implement new versions, playing with CIQ etc but customer service I've had to provide so far took me enough time that I decided I can report it and ask community for some solution or guidance. If number of such cases grows I will get back to those ideas to direct users to others apps etc.

 Thanks to you both a lot for your answers, i just hoped there is some obvious aspect that I'm missing like additional field in manifest like version control that I was missing or the topic was already known and investigated.

Honestly I have much more issues which me or my users found that I just have not enough time to report and/or discuss with community/support - I would have report them all but based on my experience those are never addressed by Garmin Support (like issues with incorrect sport type, language related resources, datafields not displayed for swimming activity etc).

SzymonP said:

I will, for sure, do so to get to know which devices can face the issue described.

Yeah, I think it’s important to note that in this case, the store’s behavior is an undesirable bug.

If Garmin is actually implementing "old devices can see the newest applicable app version” as a feature, I think they should go the Apple route and allow the user to opt out (or force them to opt in.)