CHARGING for something in the App store? Isn't this forbidden?

Just because you don't see a feature, doesn't mean that it isn't there or isn't being worked on. You can access user-defined heart rate zones with the UserProfile.getHeartRateZones() method. It has been there for a while now. You can collect your own lap data by using the DataField.onTimerLap() (I have a hunch Garmin doesn't keep all of the lap data in memory, so providing access to it might not be cheap). The accent color would be a nice-to-have, and navigation data was recently added to ConnectIQ but most devices don't have support for it yet.

ConnectIQ is growing and expanding. Yes, it would be great if version 1.0 had a complete and fully functioning API, but that would have been a very expensive endeavor with no way to be sure that it would pay off. It started out small, and is building slowly.

ConnectIQ may have started out small, but other vendors are coming on fast. Garmin has been in the lead for a long time, but I feel like they are taking that lead for granted. It's true that investing heavily in a product/technology offers no guarantee that it will pay off. However, I think it's even more true that if you don't invest enough in a product/technology to fully implement it then you *can* guarantee that it won't pay off.

Just to be clear - I'm a great fan of Garmin wearables which I've been using continuously for so long now that I can't even remember what my first device was! And with the advent of ConnectIQ I can stop complaining about the feature set Garmin put into a device and add my own! Having said that, it's my perception (which may of course be inaccurate) of Garmin's wearable product development strategy that troubles me. Yes, new devices get new functionality along with their new APIs. But it also seems that older devices - though not very old - are abandoned pretty quickly, without finishing their firmware or adding basic functionality to the API which supports them. Taking the Epix as an example, the standard watch face doesn't even show AM/PM in the 12-hour mode, and you cannot snooze or turn off the alarm using the buttons (which are identified for the purpose on the screen). No - not critical features, just examples of omissions/bugs in basic functionality that haven't - and it seems will never be fixed. More important to me as an Epix user is the fact that I can only load three (3, count em'!) data fields on the device (not in an activity - but literally on the device) at one time without crashing it. I've reported the issue to Garmin (and confirmed it with two other Epix users), but I have no sense that it will get addressed. Even more important to me as a developer is the lack of support for (what I consider to be) basic properties/methods such as getHeartRateZones and onTimerLap (to name a few), and the inability to gain access to even the most fundamental navigation properties (such as offCourseDistance) - in a device whose unique feature set is so strong on navigation/mapping features. And - why would you create an API for a device which does appear to have a machine-readable, unique identifier (or at least I see one in the GarminDevice.xml file) which doesn't expose that identifier to the developer?

Yes, it does cost $$$ to update firmware and APIs. But it costs even more to develop completely new devices and the tooling and processes to manufacture them. The "soft" in software is what makes it so powerful. Once you have a platform with sensors, processor, memory, connectivity and a user interface, then you need only improve the soft (or firm)ware to enhance what can be delivered to the user. That would seem to be a modest incremental cost as compared to what it takes to create yet-another-device. Obviously I'm expressing my opinion as an outsider. But I've been a software developer since before PCs existed, so I have some sense of what goes on under the hood. When I look at the properties exposed - and not - in the API, I have a difficult time imagining the reason why some things are available (such as the background color) while others (such as the accent color) are not - especially when such things appear to be "two things of the same kind in the same place". Once the code is written to implement one within the API, it seems logical (to me) that it would take a relatively small effort to implement the other. Unless - of course - your manager is hovering over you and you have limited time to get out a working V1. So then you do "one property of each type", and plan to go back and add the others after you get V1 working. Except, perhaps by then management has re-tasked you to work on the next device and the new API?

Again - conjecture on my part, and not meaning to criticize the Garmin development staff who has and continues to do amazing things! But it feels like whomever is controlling the development priorities and budget is all about getting the next new device to market, and let's not worry about the devices we already have in the field. I'm concerned about the future of Garmin wearables. Up to this point, from my point of view Garmin has been the only real show in town for serious athletes and weekend warriors. But other vendors are hard at work releasing new products into the wearables market segment. I gave Apple as an example of a company that robustly supports their older devices, releasing new versions of iOS that refresh them at the same as they introduce a new hardware device. Apple also knows how to support developers and they don't leave functionality out of their APIs just because "we don't think you'll need it". If the next generation Apple Watch gains a few more hardware features then I don't think it will take too long for them to start taking market share from Garmin wearables.

Apologies for rambling! I just hate seeing such fantastic devices being abandoned by their manufacturer before they have even reached their full potential.