Did you know on average a typical app uses 18 third-party SDKs, and more if it’s a game?
SDK bloat and fatigue starts innocently enough with product and engineering teams asking the wholly legitimate question:
How can I collect the data and use the services I need to make my app better and my business successful
There are numerous 3rd party integrations and SDKs available to help you do this, as illustrated in the chart below. But before you know it, you’re using so many SDKs, your apps are bloated and fatigued with performance, instability, and security issues which ultimately—and ironically—result in a poor experience for your users.
While it’s generally true that if you want to deliver top quality mobile experiences, you’ll need a way to understand user behavior and personalize those experiences, it’s also important to consider the impact these additions are having on your app’s performance.
In a recent webinar with mParticle, we discussed how HeadSpin’s performance insights and mParticle’s SDK abstraction can help you make better choices and improve mobile user experience for your apps. Below are some of the key points covered.
What are the tell-tale signs that your app is suffering from SDK bloat and fatigue?
1.) Slow app builds
You’re super stoked about the awesome app you’ve built in Xcode or Android Studio—but the app builds are annoyingly slow. This may eat away at your productivity, but you figure it’s not really a showstopper, you can live with it. But those slow builds are an early indicator that you’ve got too much building in your app.
2.) Dependency hell
Learning new APIs and keeping up with SDK updates is a constant drain on your time. And issues are compounded when your app has too many dependencies. If you’re running into issues with a dependency which relies on another dependency which has a conflict with this other dependency, your app is a likely candidate for SDK bloat.
3.) Stability and performance issues
What happens after you release your app into the world? When real customers start complaining about things like crashes, network issues, overall wonkiness, and slow performance, chances are these are caused by architectural or bloat issues. Don’t wait for poor reviews before you do something about this.
4.) Security risk
There is the problem you know and the problem you don’t know. Every single item that ends up in your app really should be audited from a security perspective or you may find yourself at risk for even more insidious issues. If you find yourself having to audit many different binaries and packages in your app, you know you probably have an SDK bloat problem.
5.) Data quality
If you find things like inconsistent naming or analytics events that are firing at the wrong time, this can point to data quality problems arising from a decentralized data strategy. This is another frequent by-product of SDK bloat and fatigue. It’s critical to keep federated data in sync. You need good data to feed into your user analytics tools for the reliable reporting you need to improve your app and grow your business.
Ultimately, if you’re using multiple SDKs and integrations, it will all add up to create bloat and fatigue in your app.
HeadSpin offers a number of different lenses of analysis that can help you identify load caused by SDKs.
1.) CPU Time by Dependency
One analysis that really helps developers is being able to see at-a-glance what the CPU time is by dependency.
How it works: You simply upload your APK or IPA to HeadSpin’s Nimble app platform along with the corresponding user flows for the app to step through. As the flow executes, Nimble analyzes the client-side performance of your application.
In the analysis that we did for one retailer (shown above), you can see that it’s not just the application native code that is eating up CPU time, but also a lot of third-party SDKs and libraries used in the app, such as AppsFlyer, ThreatMetrics, Appboy, etc. We can run this analysis for different scenarios, like cold or warm startups, or other critical user journeys, to see what proportion of CPU time these SDKs are consuming during these activities.
2.) Network Calls Made by SDKs
Another helpful analysis with HeadSpin is the ability to see not just which SDKs are being loaded, but also all the network calls being made by third-party SDKs.
How it works: HeadSpin executes performance tests on your app running on real networks and devices in our global infrastructure, and our AI engine automatically analyzes all the client-server traffic to generate a dashboard that visualizes and prioritizes the factors impacting your app’s performance.
Waiting for slow splash screens when launching an app is something we can all relate to. In our analysis of the cold start for one app (shown below), we immediately noticed a number of SDKs, such as Crashlytics and Adjust, that were being loaded during the app delegate phase. In particular, a TCP connection (in orange) stood out for taking a disproportionately long time, especially in relation to the TLS handshake (in purple). The connection was being opened by the Adjust SDK, and when we looked up the destination IP address, it turned out the SDK was trying to connect to the company’s location all the way in Germany before any other app activities could take place.
Now, let’s consider another analysis we did. We found that users of their app had to wait 16 seconds before their first opportunity to interact with the app, represented by the metric time to interact (TTI). Drilling in further, we saw that calls to a social app were being serially loaded and this was contributing to 5.3 seconds of this time.
Similarly, in the analysis we did for one finance app, 3rd party SDKs were a major contributor to slow launch time. For instance, we saw that UrbanAirship hosted on Google was redirecting to Asia, not the US as it should have.
Network calls like this can be a black box for developers, especially if you’re using CocoaPods or another dependency manager to import the SDK. But the implications can really add up in terms of client-server performance, especially if a large number of calls are being made.
What can you do to reduce bloat and fatigue in your apps? Here’s what we recommend:
HeadSpin monitors, measures, and makes recommendations to improve mobile performance across applications, devices, and networks—no SDK required. The mParticle platform is designed to be your SDK abstraction layer and data hub, and does the work of integrating with each individual app service so you don’t have to. Used together they can:
If you’d like to learn more about SDK bloat and how we can help, check out our on-demand webinar with Jeena James, VP of Developer Products at HeadSpin, Nathan Krishnan, Head of Customer Success at HeadSpin, and Sam Dozer, Sr. Director of Engineering at mParticle.