The Painful journey of Developing apps for Connect IQ / Garmin

We run one of the larger Garmin apps on the Connect IQ store.Our app does activity tracking with advanced sensor fusion based on the accelerometer, gyroscope and GPS. 

On Apple/iOS our app scores 4.8 stars; on Garmin we struggle to stay above 3.5.

The truth is that this is not our fault. Over and over again we run into issues with Garmin. Every other week we see a spike in our support volume (tens of tickets) because of another Garmin problem. Even though Garmin users are around 30% of our total users, they are around 90% of our support load. 

A few recent examples:

  • The new Forerunner 170. Garmin did not expose the gyroscope to Connect IQ apps, so our app works on paper (the watch has a gyroscope) but not in practice. Result: negative reviews and several support tickets.
  • The new sensor timestamps (includeTimestamps), which are finally available, show structural problems on some watches. Very often the timestamps burst: instead of one sample every 10 ms, as you would expect from a 100 Hz sensor, we get 100 samples within a few milliseconds and then nothing for the rest of the second.
  • The new Fenix 9. On the Pro models, more than half of all sessions lose GPS for Connect IQ apps. The behaviour is always the same: after about 14 seconds the GPS stops recording. This issue is still hot. Result: complaining users and negative reviews.

Because of our scale we find issues within no-time and often are the first to report it, especially anything related to sensors. I'm sure many developers aren't even realising some of the bugs, as some of them only affect a fraction of the units (not models -> units). There are bugs that affect a full model, there are also bugs that affect units within the same model - these are the most annoying ones, because it's hard to reproduce if you don't own a failing unit from the same model. Small apps probably never even notice this, but the user is frustrated nonetheless.  

On average every other week there is a new problem, and it takes forever for Garmin to resolve it. It looks like Connect IQ is not a priority. I have some direct contacts at Garmin, and whenever I report a critical bug like the ones above, the reaction is annoyance rather than thanks for reporting a basic flaw.

Very often a problem is not tied to a specific model or software version. We have also proven that within one model, e.g. the Fenix 6, one unit works and another does not. There is no consistency, most likely because of different hardware batches or suppliers.

On top of that, when we refer users to Garmin support, because the issue is not one we can resolve, 9 out of 10 times they come back with "Garmin says it's a problem with the app.". The default reaction of the first line support is to deny the issue, and refer back to the app developer. It's obviously extremely annoying when I have 100x better understanding of an issue to have to argue with a first line Garmin support employee. 

I understand that maintaining 150+ watch models and their software is difficult. But could the team please include some basic test cases? I am happy to provide a test app for automated testing. Honestly, checking whether GPS and the gyroscope work for Connect IQ apps should be part of the most basic test set for any watch.

  • You need to post specific examples with the code. This doesn't seem to be a common issue. 

    I have a number of apps with 100k+ downloads and support devices back to the beginning of CIQ that are sill downloaded and used today

  • I recognise this unfortunately.
    In SDK 9.1 Garmin added getPowerZones, the method is not testable in the Simulator and it doesn't work on all devices it should work on.
    https://forums.garmin.com/developer/connect-iq/f/discussion/436177/how-to-get-zones-from-method-userprofile-getpowerzones?pifragment-1298=2#pifragment-1298=2

    I reported a bug, SDK 9.2 came out in June and the bug was not fixed. Now it's already October and nothing seems to happen, no new SDK for 4 months.

    How could you even claim to have added a method that we cannot use in the simulator? 
    I have been a software developer for years and I wonder if Garmin knows about regular stuff like unit tests and integration tests. 

    Every now and then I boot Windows to see if anything has been fixed. (I would love a good SDK for Linux)

  • Hi Jim, This topic was not meant to be discussing examples, at least not from my side. The point is to see if other developers also experience the Garmin developer experience to be very poor. And I'm not even talking about the developer documentation, which is poor also. I'm talking about the experience of hunting bugs that trace back to weird issues / glitches in Garmins software and/or hardware. Once again, this is not really about the examples. I guess it's more frustration that I receive bad reviews on my app, only on Garmin, out of my own control.

  • 4 months isn't unusual for an SDK.  In the case of GPS on the f9 and configurations, I know others are waiting too.  I'm still trying to get the bonding to work with BLE, etc.

    There are many cases where the sim doesn't work like real devices and never will.  Starting with things that are a native view on devices, and MapView, MapTrackView, SensorHistory, etc.  With SensorHistry, in the sim you only get canned data for example.  With maps it doesn't use the same ones as real devices.

  • I’ve had very similar experiences. One of the biggest pain points is the discrepancy between the simulator and physical devices. Apps run flawlessly in testing, only to launch into a black screen on the actual watch. 

    I ran into another issue where an app caused the flashlight hotkey to stop responding reliably (working maybe 1 out of 5 times). A user confirmed the exact same behavior with several other apps. I documented and posted the bug on the forum, only to be met with complete radio silence. No response from staff, nothing. At this point, I don't expect it to be addressed anytime soon.

    Garmin has always been a hardware-first company, and software clearly takes a backseat. You can see it throughout this forum: the Connect IQ team seems severely understaffed and lacks the engineering bandwidth to follow up on critical platform bugs. The hardware is top-tier, but the software ecosystem is constantly holding it back.

  • There is a definite learning curve with CIQ, even for long time programmers, and that includes device/sim difference and tracking down bugs on real devices.  Just knowing what in the API. Understanding the CIQ_LOG file, etc.