Is it possible to change the app type of a released app?

I released an app on the CIQ store as an Device App and now realized it should have been a Widget so it supports glances on older devices, Is it possible to change the app type without submitting a new app and losing your downloads and reviews?

  • It's been a while, but a few years back I tried and the answer is "no"  If I recall, when attempting to upload, I got an error about the app type being wrong.

  • Did you ever get an official answer to this or did you end up pulling down and uploading a new version? If the latter, did you try to get your existing users to migrate somehow like adding a new version of the old app prompting them to do so?

  • I did end up having to upload a new Widget app to the store and add a QR code with a link to the new app that shows when you open the old app.

    Ironically enough i had to upload yet another version later because i needed some Device App functionality back in the app, but now i have both a App and Widget version with different capabilities.

  • Alright, that's a shame but nicely solved with the QR code!

    Re. your last sentence, not sure I follow. Isn't building the app as a widget making it both a widget for old devices and an app with glance (widget) for newer devices? Or do you mean you'll have to have two separate apps, one widget and one device app, for devices running SDK before version 4.0.0?

  • Isn't building the app as a widget making it both a widget for old devices and an app with glance (widget) for newer devices?

    To be clear:

    - an app with a type of widget in the manifest will actually be compiled with a type of watch-app (device app) for CIQ 4+ devices. That's why if you tried to sideload a widget app built for an older device on to a CIQ 4 device, you'll get an error. (I think it's a moot point now - afaict, it's no longer possible to sideload a PRG built for a different device onto a newer device, period.)

    - for CIQ 4+ devices, apps have to explicitly provide a glance view, by implementing getGlanceView().

    Why is this important? Old (CIQ 3) devices which support glances will automatically provide a default glance view for apps with type widget, when getGlanceView() is not provided. (This default glance view consists of the launcher icon and app name). This means that devs who initially created a widget for really old devices - that only support full screen widgets and not glances - could easily port their widgets over to CIQ 3 devices supporting glances, without significant (or any) code changes. But if the same app is ported to a CIQ 4 device, there will be no default glance view. It's actually happened more than once that one of these old widget apps has been ported to new devices, and users have found that there's no glance, because the dev didn't implement getGlanceView() (perhaps because they didn't know they had to.) It's a problem because these apps are really designed to be used as widgets (e.g. to be accessible during an activity).

    Personally I wish Garmin would issue a compiler warning for apps with type widget, no getGlanceView(), and built for CIQ 4+ devices. This warning would tell the dev that they should implement getGlanceView() if they want a glance view. Even better, the compiler could generate a default glance view in this case. I doubt either of those things will ever happen (especially since it's really only a problem for old apps).

    Or do you mean you'll have to have two separate apps, one widget and one device app, for devices running SDK before version 4.0.0?

    Yeah my interpretation is that they need device app functionality (such as activity recording) for older devices, so they decided to re-release the app as a device app for older devices.

  • Why do you need the QR code?

    1. I would only compile the widget for the old devices. So most people when they search in Connect IQ app they'll only find either the widget or the device app, depending on the device they have

    2. For those who find it via web search (thus they see both apps, so they can end up on the "wrong" one) you can add a link to the other app to the description. Links always work, no need for camera, etc.

  • Thanks for elaborating, it's not been super clear to me but at least I interpreted the docs just like your description.

    My use case is that I don't need any app functionality but would rather build it as a widget. Sadly when I did the original version of the app I compiled and uploaded it as a device app because I didn't know better. I know that just by implement getGlanceView() I can get the desired behavior for newer devices but I want to support this for older devices too. From your summary, which is how I interpreted it as well, my options are to either not support widgets for older devices and have them use it as a device app or remove the current version and upload a new one which will be identical for newer devices but a widget instead of device app for older devices?

    Since the result for newer devices is identical, I actually think it does make sense to allow changing from a device app to a widget if your app doesn't use any APIs not available for widgets. I filed this issue as a feature request, do you think that makes sense or do you think my use case is odd?

  • For me the main goal would be to inform current users so they don't get a stale app and new versions. I think it's more common that people enable auto updates than users regularly browsing the app store for apps with features they already have. So it would be to migrate users over to the new app basically.

  • I don't really understand. Maybe I misunderstood.

    I thought that you 1st had app A (Device App). So this can't be compiled for old devices, only new devices see it. No old device can install it.

    Then to enable old devices to use your app you created app B (Widget), and you compiled it for all possible devices (old and new) and added a QR code to send people to the new app.

    Then you added another app C (Device App) to add new functions that app B (Widget) can't have? I'm not sure about this, maybe you used app A for this.

    Anyway the things I pointed out are:

    1. no need to compile app B (Widget) for new devices, in fact it's better not to compile it (especially if there is new functionality either in app A or app C that is not present in app B)

    2. QR code is not very useful because you need a camera (probably mobile phone) to read it. I for example would probably see the QR code in the Connect IQ app on the phone screen but wouldn't be able to read it with the same phone. Maybe I misunderstood this. Is the Widget app on the watch displaying the QR code instead???

    Either way, in both app's description I would include a link to the other app.

    If the QR code is displayed on the watch, I would even then open the website of the other app, that will be opened in the default browser on the phone, and IMHO that will open it in the Connect IQ app on the phone.

  • I think Bleach is saying that they started with a device app (with a glance view) that supported both old and new devices.

    Then they realized that they wanted old devices to have a glance view, so they wanted to change their app to a widget. Since that's not possible, they updated the existing app so it displays a QR code to users of old devices which directs them to a new widget.

    But then they also wanted device app functionality on old devices (perhaps activity recording?), so it seems they released a 3rd app to fulfill this.

    To recap:

    1st app = device app with glance view (both old and new devices, but ofc old devices don't get the glance view).

    2nd app = widget (for old devices). (The 1st app directs users with old devices to install the 2nd app, with a QR code)

    3rd app = device app for (old devices)

    QR code is not very useful because you need a camera (probably mobile phone) to read it. I for example would probably see the QR code in the Connect IQ app on the phone screen but wouldn't be able to read it with the same phone. Maybe I misunderstood this. Is the Widget app on the watch displaying the QR code instead???

    Either way, in both app's description I would include a link to the other app.

    If the QR code is displayed on the watch, I would even then open the website of the other app, that will be opened in the default browser on the phone, and IMHO that will open it in the Connect IQ app on the phone.

    You can typically read a QR code from a screenshot with a 3rd-party app, although it may not be as convenient as the built-in QR code feature (which uses the camera) and it may not have the same functionality.

    But I think Bleach was talking about a QR code that's displayed on the watch itself:

    QR code with a link to the new app that shows when you open the old app.