The problem I kept hitting as a Garmin dev: once an app ships, you're mostly flying blind. The store page gives you a rounded install count and nothing else, no breakdown by device, version or country, no idea if a firmware update broke something for one watch model. Garmin does have ERA for crash reporting, but it's coarse, you get a ciq_log file per crash with no easy way to correlate it with your own app state, no aggregation across users, and no visibility into installs or usage at all. iOS and Android devs have had Firebase and App Store Connect for over a decade. We've mostly just gotten used to not having anything close to that.
So I built Tinymetrix. It's a small SDK (a Connect IQ barrel) you add to your project that tracks installs, active devices, breakdown by device/version/country, and logs crashes and errors with your own context attached, custom events, user properties, whatever you want tagged onto an error before it happens, not just a raw stack trace after the fact. Metrics get sent to Tinymetrix's backend, and you view them in a dashboard once you sign up and register your app there.
Integration, roughly:
1. Create an account on tinymetrix.com and register your app to get a token.
2. Download the barrel and add it as a dependency in your jungle file.
3. Initialize it in your app's entry point with that token, and optionally call logInfo/logError/track wherever you want extra visibility.
The part I take most seriously is the size cost, since I know background memory is tight on older devices. Current measured overhead is roughly 10 to 13 KB depending on how old/constrained the device is, measured per device rather than guessed. Happy to share the numbers for specific devices if anyone wants to check before adding it.
The client SDK, the actual barrel that runs inside your app, is open source: github.com/tinymetrix/client (Apache 2.0). If you want to take a look at the code, report an issue, or contribute, it's all there. Two example apps in there too (a watch face and a widget) if you'd rather see it wired up than read through the whole thing.
There's a free plan and it's meant to stay genuinely usable, not a crippled trial, the goal is every Garmin dev having a real baseline of analytics to improve their apps, not just the ones who can pay. Running the backend costs money though, so extra features and longer data retention are what's paid, not the basics.
Installs and crashes solve the visibility problem, but they're not the only thing missing here. No easy way to sell anything in-app, no way to see how your app is actually doing in the store over time beyond a snapshot, no way to fix a bad default without a full review cycle. I have loose ideas about some of that, nothing built yet, curious if any of it would actually be useful to you, or if the real gap for you is something else entirely.
Genuinely want feedback on this, and to hear what problems you're running into that this doesn't solve, that's what actually shapes what gets built next. And if cost ends up being the reason you don't try it, say so, I'd rather sort you out a code than have that be the blocker.
What's the thing that would actually stop you from adding something like this to your app? That kind of pushback is more useful to me than anything else in this post, so tell me if I'm wrong about parts of this too.
