This short post is about a small application I wrote to track developer stats, named My Dev Statistics. If you want to skip to the finished product, you can find the application on both the iOS App Store and Google Play.

For a long time now, I've wanted to build something small and handy to gauge audience reach for open source packages I've written, or repositories I've published. I'm an analytical guy who enjoys numbers and statistics, and I figured I'd finally take the time to write a small mobile application which would aid me in this aspect. I've long wanted to get back into the mobile side of development, and figured this would be a nice little hobby project.

My base goal was to write an application which visualizes the number of downloads that open source packages have. Although people tend to tell you that these numbers are worthless (this number can be easily inflated due to things like CI builds), it is still very useful for seeing which of your packages are the most popular when viewed relatively. This simple statistic enables me to focus my efforts on packages I may not be thinking about, as I know where most of my users spend their time. Of course there's more to it though; it would be a lie to say that this does not also provide a small amount of pride when seeing a package being used by hundreds, or even thousands, of people.

Although it's possible to browse web interfaces to view the download counts for a specific package, I have wanted to be able to aggregate this data in a single place. I personally have packages on Hex.pm, npmjs.org and more recently crates.io. Each of these services provides an API to retrieve your project downloads, and so what I've really wanted is a place to see all of this at once. I considered a web service, but as that requires infrastructure costs. I have avoided costs initially as there may be no traction, and I don't want to end up supporting something without revenue. Going for a mobile app seemed a good idea; it's free to run (as all API interaction comes from the users device), and any revenue it brings can potentially fund a small web API that offers the same features and more in the future.

The application itself is extremely simple in terms of UI; I didn't have much time to sink into this project (it already took around a month of side work due to learning Flutter). The UI it offers is pretty straightforward, because I didn't feel the need for anything flashy with something so simple:

my-dev-statistics-ios

You can tap into any of these registries to view the individual packages (alongside their download totals) inside the attached account. If you have multiple accounts, you'll instead go to an account listing where you can see the downloads per account and from there you can tap into the package listing. The image above is obviously horribly downscaled, so it does look a lot better on device, and no, those are not my personal statistics!

Everything is actually written in Dart, because I wanted to explode Google's latest Flutter engine. Although Flutter was pretty straightforward to pick up (and I love it on Android), the iOS designs for certain widgets left me having to implement my own when going for a more iOS-style feel. One thing that struck me specifically (as I use an iPhone day-to-day) was the default refresh indicator; it immediately felt very alien on iOS and there wasn't a straightforward alternative in the Cupertino libraries. Beyond that though, Dart as a language has come a long way, and the UI interactions in Flutter are definitely a different paradigm. All application logic is entirely on the users device; there is no reliance on a backing server for anything - this is partly due to wanting to avoid having to maintain a server if nobody buys it! It makes good use of async runtimes to work quickly when calling through the APIs, and provides a small caching layer in case you come back when the device is offline. It's really quite simple; although there's a fair bit of complexity in the actual API handshakes (because every registry is different, of course!).

As you can see from the screenshot above, I added support for some popular registries beyond those I use in the interest of completeness. You can also add GitHub accounts to keep track of asset and release downloads, if you distribute that way rather than through a package manager. If there are any package managers missing which provide the necessary APIs for retrieving statistics, feel free to ping me and let me know and I'll happily add support. The list above covers the interaction of the package repositories I knew of, and those which offered APIs to retrieve the required statistics

In future, based on any revenue made from this app, I would like to turn this into a much broader metric set for developers and actually go into things like graphing interaction over time, displaying dependent package counts, separate transitive downloads vs. direct downloads, etc. These things would likely require a fair bit of extra work and perhaps the introduction of a backend, so I'm putting it on hold until I receive any feedback on the initial implementation (although these are features I would also like personally, so I'm eager for an excuse to work on them!).

The application is named My Dev Statistics and lives in both the iOS and Android app stores. If you're as into download statistics as I have become, or you just enjoy reading my content, feel free to grab it! I appreciate all feedback and suggestions as I'm quite weak at mobile UX specifically, so let me know your thoughts!