I don't know if anyone at Garmin has noticed or taken interest, but any time a datafield is created that is useful to anyone at all, the developer is almost instantly inundated with requests to create "app clones" so:
- Users can have the same data field twice in the same activity, with different settings
- Users can have different settings for different activities
At current count I have 12 clones for 3 apps, with another clone or two coming on the way. If anyone was actually interested in some of the newer apps I made, well, when they click on my dev name, all they'll see are these stupid clones, because they all start with "A".
I have seen a similar situation with other data field apps from other devs (especially full page data screens) where the store is flooded with almost identical apps from the same dev.
Not only is this potentially confusing for users, it's also incredibly draining to update all of these clones whenever an app is changed. Sure, converting a single project to multiple clones is easy enough to do using links in Eclipse (but it still takes work), and building multiple clones can be scripted, but the process of uploading X clones for every app is not fun, especially with the store issues which reject updated descriptions / screenshots.
It would be really great if Garmin could have some sort of solution for this obvious user need which would make both devs and users happy. Like maybe the cloning process could be built into the store? It could be like multi language support, where you specify different resources for each of the clones (where necessary).
I only create clones because the whole point of developing apps is to try to make users happy, but sometimes I wonder if there's any point in doubling, tripling or quadrupling the stress of updating an app to make maybe 10-100 actual, regular users happy.
This is just another example of a less-than-ideal workflow / workaround that devs have adopted because of something that is missing or broken in the Garmin ecosystem.
Other examples:
- Reminding users to include their email, otherwise devs can't reply to their requests
- Telling users not to use Garmin Connect to update app settings because "it doesn't work for everyone"
- Reminding users to de-select their watchface before uninstalling it
- Moving documentation to an external site because the store page isn't suitable for docs
I'm sure I've missed a few there.
To be clear, all of this is additional work performed by devs to make their apps halfway usable for Garmin users. Pretty sure 99.99% of this stuff is either free or donationware. So that's a ton of free labour performed to make Garmin users happy. To be crystal-clear, a user has actually talked about buying a certain really expensive Garmin watch because of a data field I wrote. Sure, it was only one user, and it was a second-hand watch, so Garmin made $0 off of that. Or maybe it was refurbished. Who knows.
But maybe Garmin's brand got ever-so-slightly shinier for that one person, who will maybe tell their friends. Net benefit to me, as a dev? Negative, since it's all time and work that I put in for free. TBH, there's no amount of money in the world that would make me enjoy certain things that I have to do to work around all the issues in the Eclipse plugin, the simulator, the app settings, the forum and the store, as well as discovering all the bugs that haven't been fixed in older products only after an app has been submitted to the store.
In five years, Garmin will still be around, hopefully. Can't say the same for sure about a rando dev like me.
I really only wanted the satisfaction of creating useful things for products I ***used*** to like. And with every new hurdle the ecosystem presents, it just gets harder and harder to do so.
I keep hearing that most CIQ devs are doing this for fun or as a hobby. That's why I'm doing it, to be sure. I wonder at what point this isn't fun at all anymore?
