Missing the bloat: Improving mobile user experience through SDK abstraction

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.

So, are you missing the bloat?

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.

Identifying performance issues with HeadSpin

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.

How to build a fitter app

What can you do to reduce bloat and fatigue in your apps? Here’s what we recommend:

• Make your app network aware: Mobile SDKs often run background processes and establish TCP connections that ultimately will wake up your mobile radio. This will not only incur the expense of network calls being made but will also contribute to battery life being siphoned from the device. Look into wrapping your SDK integration calls behind connectivity checks. You can use the Telephony Manager (Android) and NWPathMonitor (iOS) libraries to query the connectivity state.
• Make decisions based on user opt-in: Load or utilize SDK features based on what users opt in to. Don’t just load SDKs at startup unless they are needed, and if the SDK allows for it, customize settings and configuration for optimum user experience.
• Remove SDK and API bloat with an abstraction layer: With mParticle you can create a data abstraction and infrastructure that helps you avoid problems like SDK bloat and improves your data quality. You can map out where the data is coming from, where it is going, and leverage all sorts of tools to control exactly how that data should look, how it should be persisted on a per user basis, and also exactly how it should be filtered for security and data governance.
• Do not accept closed-source SDKs into your app: Every additional binary in your app has an impact on its performance and stability. Things like main thread access, wake-locks, crashes, etc. can all lead to issues. Sam Dozer from mParticle put together an App Developer’s Bill of Rights that basically says you have a right to take full ownership of the quality and maintainability of your app.
• Consider reducing user tracking: Do you really need to fire off tracking requests to so many domains? This is not only bad for app performance and battery usage, but actually makes a poor impression on your users. Consider that consumers these days are going so far as to proxy their devices to avoid this.

Watch our webinar

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:

• Identify and eliminate performance-impacting overhead
• Minimize app bloat and architecture complexity
• Collect and activate valuable app engagement data without taking time away from engineers’ core development cycles
• Maintain visibility across your entire infrastructure

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.

‍