Mobile SDKs are incredibly powerful. They can provide a multitude of functionality that helps you achieve your business goals.

But that power comes at a price. Every SDK you add is a decision that shouldn’t be taken lightly because there is a hidden cost in performance and app size. Your users will have to endure the performance hits from every SDK, and if you aren’t paying attention, this problem gets big enough to induce user churn.

To make the best decisions for your business and your users, you should monitor the true impact of every SDK.

In this blog post, we’ll cover:

  • Why are SDKs even a problem?
  • Why should you limit your SDKs?
  • What is an ideal number of SDKs?
  • What separates good SDKs from bad ones?
  • How do you know if your SDKs are causing problems?

Why are SDKs even a problem?

We’ve mentioned above the performance cost associated with SDKs. At their core, SDKs are code someone else wrote to produce functionality within mobile applications. Remember that this code isn’t necessarily optimized for your app’s specific use case. That means your team faces the fundamental buy versus build decision. They could probably build something far more efficient given enough time and resources. Or they could access that functionality with a few lines of integration code.

Since adding an SDK is very easy, most mobile teams end up overusing SDKs. This happens particularly when a mobile team is trying to grow their app at a breakneck speed, causing them to lean towards adding SDKs as an easy way to add features and functionality. Because velocity is so important, teams rely on these third-party solutions to achieve the desired results.

As the mobile ecosystem has matured, there’s been an explosion of third-party SDKs on the market. Just look at the sheer number of categories there are based on Get Social’s list of SDKs:

Testing

  • Testing & Beta Testing
  • Crash Reporting & Bug Reporting
  • A/B Testing

Acquisition & engagement

  • Communication
  • Engagement / Marketing Automation
  • Notifications
  • Attribution / Deep Linking
  • Acquisition & Retargeting

Others

  • Authentication
  • BaaS
  • AR / VR

Location

  • Location
  • Mapping

Monetization

  • Payments
  • Ads & Monetization

Insights

  • Performance
  • Analytics
  • Data Hubs
  • App Store Intelligence

Let’s just say that mobile teams are not suffering from a lack of options. There’s so many SDKs out there that there is probably an SDK for the feature or function you need. This is why the desire for mobile teams to “just go find and add the SDK for that” is huge! But then again, too much of a good thing can be bad too. Which brings us to…

Why should you limit your SDKs?

One big reason is to reduce your app download size. In a previous study, Segment found that apps that were larger than the download limit (100MB for Android or 200MB for iOS) suffered a 66% loss of installs. Such a huge drop in downloads would affect your app’s ranking and discoverability. And this is not even mentioning the negative reviews about how your app’s download size is eating up a huge percentage of users’ data plans.

By limiting your SDK count, you limit the surface area possible for outright failures. Keep in mind that SDK vendors have bugs that can crash your app, which also contributes to bad reviews and lowers your install rate. A good example is the Facebook SDK outage that triggered crashes for multiple iOS apps. When a third-party SDK causes your app to crash, your mobile teams’ hands are tied because they can’t just go into user devices and force an upgrade to a version without the offending SDK. No, your team is forced to wait for the third-party to resolve it on their end. But during that time, users don’t care that you have no control over the situation — the app is crashing and that is your fault. 1 star review coming right up.

App performance issues can often be directly attributed to SDKs. A great example is slow startup time. Third-party SDKs can fire excessive and blocking network calls that greatly increase the amount of time your users have to wait before using your app. This often happens as a result of conflicting priorities. For example, an ad SDK might fire a blocking network call to send attribution data as quickly as possible. If your app’s own functionality is delayed as a result, so be it.

Performance issues aren’t even the worst thing that can result from a third-party SDK. What if a third-party SDK (again, code that you did not write and is not under your control) breaks the app store’s rules and gets your app pulled? With increased attention on user privacy and requiring explicit permission to track users, this has already started happening. Your app could have updates rejected, or worse, get pulled from the app stores outright. Thus, it’s important to carefully vet your SDKs, and only use ones from trustworthy vendors.

What is an ideal number of SDKs?

SafeDK reports the average number of SDKs on Android is 18, but this can be higher in gaming apps. But does that mean your mobile team should be aiming for that number?

We tell our partners to shoot for 10 SDKs or less. That is a realistic number that teams can achieve if they are diligent about only using SDKs they really need. It is not uncommon for us to help a partner investigate their app’s issues only to find they have SDKs that they aren’t even using. There can be many reasons for this, such as SDKs from expired free trials and SDKs that were put in for a specific reason and are no longer in use. These vestigial SDKs are bad for your app and should be removed as soon as possible.

We have a eBook — Rev up your mobile app startup time — that can help your team deliver an optimized startup time that delights your users.

In the meantime, here’s a short list of what you should be doing to ensure your SDKs are not negatively impacting your app:

  1. Audit your SDKs constantly

Do you really need five different advertisement SDKs?

Do you really need multiple crash reporters?

Do you really need several product analytic tools?

2. Consolidate SDKs whenever possible

You want to use SDKs that provide the function of multiple SDKs. A good example is Embrace, which provides crash reporting, logging, performance monitoring, network monitoring, real-time dashboards, proactive alerting, and observability all in one.

This requires less upkeep because you are using one efficient SDK instead of stringing together functionality from multiple SDKs to get the same result.

What separates good SDKs from bad ones?

So how do you determine if an SDK is good? Here’s a list of attributes we commonly associate with SDKs worth keeping:

  • Good SDKs are lightweight and performant. They are written to minimize the amount of code.
  • Good SDKs are actively maintained. They support the newest OS versions.
  • Good SDKs are simple to integrate.
  • Good SDKs have good documentation.
  • Good SDKs have no bugs.
  • Good SDKs play nice with other SDKs.

On the flip side, there are bad SDKs that have the opposite of the above. These are rarely worth keeping:

  • Bad SDKs are needlessly heavy and bloat your app’s size.
  • Bad SDKs lack support or don’t follow through on their feature roadmap.
  • Bad SDKs have documentation that is a confusing mess.
  • Bad SDKs actively compete against your application for resources.
  • Bad SDKs have lots of bugs.
  • Bad SDKs do not play well with other SDKs.

And a third category of temporary SDKs you keep until you find a better solution:

  • Temporary SDKs have features you plan on building soon.
  • Temporary SDKs will be replaced when you look for a consolidating SDK.
  • Temporary SDKs that you are merely testing for use.

Keep in mind that the bad SDKs should be removed as soon as possible, and temporary SDKs should never outstay their welcome. Don’t let temporary SDKs clog up your app!

How do you know if your SDKs are causing problems?

Now that you know the SDK categories, how do you go about categorizing them? In short, how can you apply this information to your SDKs to inform long-term decisions about them?

The best practice is to monitor and track your app’s performance and stability metrics over time. For example, if your app’s crash rate doubles after introducing an SDK, you know to immediately investigate that SDK.

This means that you will need a tool that can do the above. Ideally, that tool gives you coverage of each individual SDK to identify the bad actors. This can further accelerate any potential fixes with an SDK, whether it’s informing the SDK’s creators that they have this issue or architecting your app to safely handle failures in the future. For example, your team could install a configuration server-side to allow remote disabling of any SDKs. That way, if an outage happens, your app can simply avoid loading the problematic SDK.

How Embrace helps mobile teams

Embrace is a data driven toolset to help mobile engineers build better experiences. We are a comprehensive solution that fully reproduces every user experience from every single session. Your team gets the data it needs to proactively identify, prioritize, and solve any issue that’s costing you users or revenue.

Want to see how Embrace can help your team grow your non-game app with best-in-class tooling and world-class support? Request a demo and see how we help teams set and exceed the KPIs that matter for their business!