Whilst we are always looking for ways to give our users a better experience, Garmin is looking for ways to sell more devices, and this is often at the expense of we long-suffering developers.
Two examples:
1. While we look at ways to exploit CIQ/SDK enhancements to enhance our users' experience on their existing devices, Garmin, to channel users into replacing their devices, is reluctant to retro-fit enhancements to existing devices.
A case in point is WatchUi.Menu2, a significant improvement to WatchUi:Menu, but only available on CIQ3 + devices. We still have a significant portion of our loyal users on Vivoactive-HR devices, which forces us into all sorts of complications when reviewing its implementation.
2. When we discover bugs in our apps, we work hard to fix them and release the repaired version as soon as possible. Garmin's response is usually very slow, and in some cases non-existent.
A case in point is the bug, now at least 2 years old, on the Fenix 5 range that causes the language name, e.g. "English" to replace our menu title in WatchUi:Menu menus. I have given up hope of that ever being fixed.
We based our initial design around the Vivoactive-hr, and when they released the Vivoactive 3 we faced our first major re-design challenge to cater for the round screen, and since then have had to accommodate the buttons of the Fenix5 and more recently the high-res AMOLED screen of the Venu and Epix devices.
Through the extensive use of jungles annotations, resourcePath and sourcePath we are currently supporting 65 different devices in a single code set, with some 22 separate configuration sets across screen shape, screen size, touch/button input and watchApp memory size. Having to cater for CIQ version is yet another consideration required to implement Menu2.
Sorry, just letting off steam, and I already feel better!
