Mobile SDKs; love them or hate them, they're here to stay. They provide our apps with all sorts of functionality that would be incredibly time consuming to build, and they give us another means to monetize our apps. Third party SDKs are in fact, quite popular. According to a study done by SafeDK, on average each Android app uses nearly 18 third party SDKs. That number is even higher for mobile games. While it would be difficult to argue that SDKs aren't useful, it's also hard for developers to get a good idea of the amount of resources used by each SDK once the app is in production.

What makes a good SDK? Some of the common factors to consider while judging the quality of an SDK are functionality, ease of use, and documentation. Some other attributes to consider are CPU usage, effect on battery, playing nice with other SDKs, and even network data usage. As we mentioned, each Android app uses 18 third party SDKs on average. It therefore is very important for all SDKs to function in harmony. The effect on CPU, battery and data consumed per session are all also important for apps because each of these could lead to users uninstalling the app. Let’s discuss data consumed per session. This is an important factor when you consider users who have limited data plans.

So how does one know which SDK is consuming the most data per session? What are the number of transfers per session? There are a number of ways you can look at the traffic requests made by various SDKs. You could route the app traffic through a proxy, run the app on your test device and see what’s happening, but unfortunately this will only show you the results of your own individual tests, giving you an idea of performance, but likely a statistically insignificant answer. Another way is to use a Mobile Application Monitoring tool such as New Relic or Apteligent. This gives you a whole suite of tools and the results would be from real productions users. The downside here is that it can get very pricey.

We often hear from mobile app developers about the need for an analytics product that would provide all the statistics for third party data transfers and would be able to capture the specific domains and URLs that are causing the largest amount of data consumption.

The chart below is from a gaming app with traffic mostly in the US and Canada with ~10K DAU (Daily Active Users). Like many mobile games, this app also relies on ads for a large portion of its revenue. Hence the preponderance of ad SDK’s in its list of data consumers.

In the chart, both ‘vid.applovin’ and ‘edge.adcolony’ are ad SDKs, but each one has different data size per session (~13Kb and ~10Kb respectively). This simply could be because ‘vid.applovin’ is serving more ads compared ‘edge.adcolony’ because that is how the developer prioritized their ads, or it could have something to do with the frequency that the ad content is refreshed or the size of the individual ads. What you do get is greater insight into what the SDKs in your app are actually doing. You should think about this as you consider which SDKs to include in your app. Mobile data is expensive (and frequently slow) for users, especially in developing countries. As app developers, it makes sense to to keep an eye on data usage metrics to accommodate a global user base.

In conclusion, there’s a real need for app developers to collect detailed network performance statistics about their apps. To be efficient, that solution would need to be:

1.) Designed from the ground up for mobile applications with Real User Monitoring (RUM) 2.) Lightweight in its metrics collection (i.e SDK uses just one UDP packet).

But that’s not all! This smart SDK should be FREE and also allow developers to compare their app performance with industry references (benchmarks) and automatically optimize their code at run-time based on thousands of different network types, locations and times faced by their apps.

Sounds too good to be true? Not necessarily! Check out: https://packetzoom.com/mobile-iq-sign-up.htmlThis content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.