Last week was Garmin’s 3rd annual Garmin Connect IQ developer event, this time called the Garmin Virtual Developer Conference since it’s all online, versus the Connect IQ Summit that was in person and held at Garmin’s headquarters in Olathe, Kansas. This conference digs into all the nitty-gritty aspects of Connect IQ, but also now developer aspects across Garmin’s entire platform, beyond just Connect IQ running on a watch. For example, this included aspects of the previous ANT+ Symposium (so, ANT+ as a technology), as well as health platform bits that aren’t really Connect IQ directly.
Now, generally speaking, we don’t typically see much in the way of product announcements as part of this. Like Apple’s annual WWDC events, there typically isn’t a big hardware splash, it’s more about the developer side. Though sometimes you’ll see ancillary announcements, but it’s rarely the big event or focus. The morning of the conference there was the minor announcement of the updated Index S2 WiFi Scale, but that’s it.
Instead, the major message of the developer conference could be summed up as:
– Consolidating all the developer programs under one agreement and request for developers to apply to
– Developers now get a single key that supports all of the developer program pillars (more on those down below)
– Increasing user control and specificity over their data sharing with other apps, especially for aspects such as women’s health data
– Announcement of Connect IQ 4.0 platform
– Widgets get deprecated in favor of apps with widget glances (which can then expand full screen like old school widgets)
– Increased graphics capabilities within CIQ4 to better take advantage of AMOLED/LCD screens
– Developer tools shift to Visual Studio Code Extension over IDE
Now, in addition to all the techie bits, there were also the various tracks you could tune in and watch. The breakouts are set to be published online next week as well, in the Garmin CIQ forums. Having watched some of the breakouts in the past, they tend to have lots of fun nuggets of info. For example a year or two ago Spotify did one where they dove into the nuances of how they made decisions as it related to their CIQ app, things like album covers and such. It was interesting. Here was the full slate, just for historical reference.
The upper first two hours had Garmin lead category managers (like the leads for the Forerunner series, Cycling units, and so on), sharing their favorite new features from the past year, along with a recap then of the upcoming developer & Connect IQ 4.0 announcements. Once they were done, I took up the bulk of the timeslot with a 45-minute ‘State of Sports Tech’ keynote that you can watch here.
And for those curious – yes, those were really the actual category managers for all those products. And indeed, the people directly in charge of those product lines. And I presume those were indeed their actual living rooms or backyards featured. Welcome to 2020.
Afterwards there were breakout tracks as you can see below. Basically the intro track for people new to Garmin development, the CIQ track for existing developers, and the business track if you weren’t a developer but more on the business side.
Ok, let’s dive through some of the bigger ticket items.
Consolidation of Developer Programs:
For as long as I’ve been covering Garmin, I’ve talked about their API’s and related things. Seriously, we’re talking way back. And as such, I’ve seen the full journey of it, perhaps also being the one poking that stick the hardest. So now basically 10 years later we’ve gone from them firing their entire Garmin Connect development team, to having a complete umbrella developer program with multiple pillars and API’s for almost every aspect of the system. Plus a platform for developing on devices as well.
Which, doesn’t mean it’s perfect. Obviously not. I’ll dive into some of those gaps in a minute. But first, let’s talk about what’s new here.
The main thing is that up until now, there was a different approval process for each of the API’s within the Garmin Developer program. So if you as a developer wanted to get activity files (e.g. workout files) to your app, you’d have to request access to that. Then, if you wanted to get structured workout support, you’d have to request access there. Then, if you wanted to get weight scale data – again, rinse…repeat.
The idea going forward is that you’ll (as a developer) request access once, and then you’ll have access to all components of the platform. As always, this doesn’t mean you get access to everyone’s data of course. A user must still approve your given app to access their data, just like you’d expect. But it means you can build out an app/platform and not have to get separate approvals for everything.
The core API pillars are:
Health API: This includes things like steps and weight scale data, basically, 24×7 data, such as for a corporate health program to see your steps
Activity API: This is for completed workouts (where you start/stop a timer), such as TrainingPeaks/Strava receiving your workout
Women’s Health API: This is for accessing female health tracking data
Training API: This is for structured workout support, such as TrainerRoad pushing workouts to Garmin devices
Courses API: This is for courses support, such as Strava/Komoot pushing courses to Garmin devices
Note that these are all API-driven pillars, not Connect IQ driven components (such as what happens on a device) – that’s more of an SDK level thing that happens in a different realm (also, my next section).
Keep in mind however one important bit: Most of these are outbound from Garmin (or read only), not inbound to Garmin. Here, let me explain:
*Health API: Reads access to 24×7 health data
*Activity API: Read access to 24×7 completed workouts
*Women’s Health API: Read access to women’s health data
Training API: This allows the app to push structured workouts to Garmin Connect & Garmin Devices
Courses API: This allows the app to push course files to Garmin Connect & Garmin Devices
*Technically speaking some of these are more ‘pushes’ of files from Garmin to the platform, but the point here being a 3rd party app can’t ‘add data’ to the Garmin Connect repository.
Here, the below shows the two groups pretty well. The first three are listed on the left below, and the second two on the right:
About now, some of you are like, wait a second…how does Zwift or TrainerRoad (and a handful of others) push completed workouts from Zwift to Garmin Connect? How do I (as an app developer) do that?
The simple answer: You don’t.
Garmin says the API that allows 3rd parties to insert data onto Garmin Connect isn’t part of this program and isn’t open. It’s behind all the secret doors. Essentially the only way you’re getting access to that is if you’re a household name in the sports world, *AND* if you don’t meaningfully compete with Garmin. In other words, they’ll call you, you won’t call them. They also noted that the engineering work on that is higher for Garmin, and thus the ROI needs to be higher.
That’s their right, sure, but I think it’s also a bit short-sighted still. I’d love to see more trainer apps in that bucket, beyond just the handful in there today. Plus, if people want their data in Garmin Connect it’s because they have a Garmin device they paid for. They want things in one place.
Now, there are two more things of note related to the API changes (both of which are good):
– The API now allows historical access to data: Previously, this wasn’t the case, and you only got a snippet of near-term data from the point of registration. Now it’s everything historical. That’s crazy cool.
– Defined access controls for users: With MCT (Menstrual Cycle Tracking) data being opened up, users can explicitly set which data they want to allow apps to have. For example, end users can allow access for the other pillars (such as activity data or health data), but not female health tracking data – similar to how today you can toggle an app to push receive completed workouts but not receive courses from a partner.
Ok with that, let’s shift over to the device bits. Oh, and remember that the cohesive umbrella developer agreement isn’t live yet today, but slated for by the end of the year.
Connect IQ 4.0:
Next, we’ve got updates to the Connect IQ platform, which are launching as part of Connect IQ 4.0. However, as of today there aren’t yet any devices to take advantage of the Connect IQ 4.0 capabilities . Garmin says that the first CIQ 4.0 devices won’t launch until 2021. Meaning that while some things such as the increased graphics capabilities clearly hint towards increased graphically capable devices. And, long-time followers of Garmin’s Connect IQ announcements know that they often hint at features ahead of actual devices being available to take advantage of those features.
Here’s the condensed list of the announcements being made:
– Widgets get deprecated in CIQ4 in favor of apps with widget glances (which can then expand full screen like old school widgets)
– Increased graphics capabilities within CIQ4 to better take advantage of AMOLED/LCD screens
– Developer tools shift to Visual Studio Code Extension over IDE
– Apps can now be launched at any time, including from an activity
– New type system for Monkey C language to help reduce errors without runtime testing
Now, there isn’t yet a ton of information available on any of these. Most of it is set to arrive soon, but the first is that they’re going to be shifting to a Visual Studio Code extension instead of the existing Eclipse environment.
Next, there’s the consolidation into widget glances. Or basically, the deprecation of full-screen widgets in CIQ4 on the widget roll. As a reminder, widget glances are shown at the left, below. Basically it lets you get three pieces of information on the screen, versus a single piece of information from a single widget. Then you’re able to expand that out to get the full widget with additional information (seen at right for the weather):
Garmin says that widgets will still be supported for older devices, but that going forward for newer devices it’s all about widget glances (and then of course, the ability to expand into more detailed full-screen widget pages). This is fine by me, as I think widget glances are one of the best things Garmin has rolled out usability-wise in the last year or so (the first device was the Fenix 6 the last few days of summer 2019).
However, what’s notable though is that these widget glances won’t be part of the widget ‘type’ anymore, but rather part of the app type, which include widget glances. Here, I modified their slide to explain it:
However, this does show one aspect where the Garmin CIQ ecosystem is far less backwards compatible than that of Apple’s (which is supporting devices in the latest OS all the way back to Apple Watch 3, launched in 2017). Whereas CIQ is only supporting 2021 and beyond devices. If we look at widget glances being rolled into apps, I truly struggle to understand a reason why that can’t be made to at least recent devices. After all, the Fenix 6 already has widget glances, and already has apps.
As Garmin matures, this sort of lack of backwards compatibility will only serve to frustrate both developers and consumers alike.
Next, in line with graphical related bits is that graphic tasks will soon load into a separate graphics pool, which gives additional resources for those operations. The main driver for this is the newer AMOLED/LCD screens (such as seen on the Garmin Venu series to date).
This would probably be your biggest clue as to the direction Garmin is going with respect to not just CIQ, but devices as well. But of course, that’s no surprise. Since the Garmin Venu last year, we’ve seen them expand that screen type into other wearable devices in the Garmin lineup, beyond just fitness-focused watches.
And finally, on the list of items, there’s a new type system for the Monkey C language, which should help reduce errors for runtime testing. I believe that was covered more in-depth in one of the later breakouts, but I wasn’t able to make that one.
Ok, that’s the core messages take away from this. Obviously, the bigger questions are which devices get CIQ4 (be it now, or in the future), and then the nuances of the implementation of all these things, which really won’t happen till developers get their hands on it.
Wrap-Up:
One of the things that’s easy to forget here is that by brand, Garmin (as covering the first half of CY2020) is now the #2 smartwatch maker (behind Apple). Which is sorta crazy. Now, that gets a bit fuzzier in some ways because Wear OS isn’t tracked by unit volume for CY2020H1, so it’s entirely plausible Wear OS might be ahead of Garmin, because the distribution numbers are consolidated among units shipped by brand (e.g. by Fossil, Huawei, Suunto, etc..) – rather than smartwatch OS. It’d be tough though (I dive into the numbers of this a bit in my presentation).
Point being, we’re talking millions of units per quarter shipped, second only to Apple (albeit, a long-ass ways away in second). But it’s enough to matter now. It’s no longer just a fun little platform for people who like to run, which is basically how it started out 6 years ago. But as illustrated in the CIQ4.0 section above, Garmin needs to really lengthen out the backwards compatibility timeframes. People buying a $2,000 MARQ series unit this holiday season should have confidence their units aren’t already digital vintage before the non-existent New Years’ Eve parties this year.
But with that also comes the platform pieces, beyond just Connect IQ as a wearables spot. Since ultimately every one of those Connect IQ capable devices is connected to Garmin Connect as the platform (and far more devices that don’t fall under the ‘smartwatch’ banner like Garmin Edge devices, or even some of the more simplistic Vivo series).
Anyways, as always, it’ll be interesting to see what apps do with all this, which usually takes 3-9 months before we see the fruits of that. For example, a few years back the addition of the music/audio Connect IQ device type is what eventually got us Spotify and Amazon Music on Garmin wearables. And then in April 2019 the addition of the structured workout sync API (Training API) is what eventually got duplicated to give us automatic sync of routes from Strava/Komoot/etc…
In most cases, the ways the announcements are phrased above, probably won’t directly be the most interesting implementations seen by next summer. Instead, developers will take the functionality and ideally do something outside the box.
With that – thanks for reading!
FOUND THIS POST USEFUL? SUPPORT THE SITE!
Hopefully, you found this post useful. The website is really a labor of love, so please consider becoming a DC RAINMAKER Supporter. This gets you an ad-free experience, and access to our (mostly) bi-monthly behind-the-scenes video series of “Shed Talkin’”.
Support DCRainMaker - Shop on Amazon
Otherwise, perhaps consider using the below link if shopping on Amazon. As an Amazon Associate, I earn from qualifying purchases. It doesn’t cost you anything extra, but your purchases help support this website a lot. It could simply be buying toilet paper, or this pizza oven we use and love.
