So it’s been a little while since we last looked at analytics for your iOS app, and as it happens we have a new one just out that could use some sober second thought on its analysis strategy going forward; let’s take a look at that today, shall we?
First off, since you don’t have to do any work to get them it’s always a good idea to keep abreast of the latest developments in App Store Connect App Analytics – especially since there’s a bunch there that you can’t get with any other service! But, since you can’t report any custom events so they’re not very interesting development-wise, we’ll just remind you of the documentation and move right along, to consider in detail the current crop of services that are FREE! and UNLIMITED! that being the tier of service that us scrappy Indies are most interested in naturally!
So, last time we were checking out this analytics thing, the buzz was all about Fabric Answers…
The best of Answers realtime analytics is now part of Firebase. New apps should use Google Analytics for Firebase…
To use the latest generation of app reporting in Google Analytics, you’ll need to install the Firebase SDK. If you do not have a Firebase project, go to firebase.google.com to get started. Once you have completed the setup, return to Google Analytics…
Personally, we’d prefer not to be tied into the Google ecosystem, particularly if we’re not depending on it for anything besides analytics, so we’ll leave the Firebase option off the table as long as possible. Besides, it isn’t completely free, although the free usage limits are generous.
For completely free to the developer, Flurry appears to still be the leader in app support suites, with push and real time analytics and advertising and remote config and all sorts of other goodies these days; come a long way since Peter Farago stopped by to say thanks for our first note on it over ten years ago and now he’s “GM & VP Flurry” at Verizon with a job description of “Making Flurry awesome(r)” so that would seem to indicate that it’s weathered its various acquisitions nicely and continues to be a solid choice going forward.
While we were developing this last project, we tried out Visual Studio App Center and were reasonably pleased with it in general — we didn’t get around to creating any specific events, but even the default session monitoring of App Center Analytics is providing useful information — it’s still maturing, but if you’re tied in to Microsoft platforms or the slowly migrating HockeyApp, this is the support suite for you! Without that, it doesn’t have a compelling use case … aside from being Not-Google. Should you find that compelling.
Another option, if you have a Facebook app as pretty much everyone does these days, is Facebook Analytics where if you’ve linked in the Facebook SDK you can see session info in Facebook’s Event Manager things logged with App Events for iOS. Not actually real time though, and you don’t get the push notifications and crash reporting and so forth of the above suites, so picking one of them is probably what most of us will be interested in.
Now, there are a veritable plethora of other analytics services out there that don’t meet the FREE! and UNLIMITED! test, any number of which may be suited enough to your particular needs to be worth their investment: here’s a few of the better recentish roundups we looked at putting together post, check them out if you have a budget:
And if you don’t want a service at all but want to host your own analytics, an excellent start on that is this:
At least it looks like it. We wouldn’t know. We’re not into self-hosting or rolling our own of anything we can possibly get away with not. But if you are, check it out and let us know how that goes for you!
And finally, whichever one of these alternatives you pick first, it’s a solid bet that you’ll be called on to change it at some point, because that’s just the way it always works, isn’t it? Here is a nicely elegant post about creating
We are going to build a layer that avoids using a static API, puts any backend APIs behind a protocol, uses the power of Swift enums and pairs each event with the pieces of data it needs to contain.
More specifically it should:
- Be easy to report new and existing events.
- Allow the data be sent to whichever analytics backend we wish to use, even multiple.
- Be testable and mockable, allowing it to be an injected dependency.
- Allow events to be reported from anywhere in the app, but encourage best practices.
- Have compile-time safety of events and their properties…
Sounds like just about the way we like to put service wrappers around our dependencies yep — so whatever analytics you choose, check that out!