We’ve all heard of mobile SDKs. These off-the-shelf mobile services, which app developers integrate in your app for many purposes: advertising and payment, analytics and social, and many many more. No doubt these SDKs are a great help in your development process. They often offer unique functionalities, simplify your coding and save you precious time and money. It’s not a surprise that the 1,000 most popular apps contain on average 15 SDKs.

But SDKs are not really your code. It is actually someone else’s code interleaved with your own, yet you are liable for it. You are responsible for it in the eyes of Apple, Google and most importantly – your users. Why is this a problem? Well, in this post, I’ll explain two major domains of risk when using SDKs, and spice it up with a few real-life stories.

1. Security, Privacy and Compliance

The dark side of app permissions

Once hosted in the application, the SDK is part of the application code and can access any user data that the application was granted access to. If the app can access users’ location, contacts or private files, so does each and every SDK in the app.

We often see Android SDKs containing code similar to this:

if (context.checkCallingOrSelfPermission(“android.permission.ACCESS_FINE_LOCATION”)
              == PackageManager.PERMISSION_GRANTED) {
     Location userLocalLocation =

The SDK simply checks if the app was granted a permission to access the user’s location, and if so it takes advantage of it and accesses the GPS as well. We can often see that SDKs send this information to external servers.

Let this be a cautionary tale to all you folks integrating SDKs: what the SDK doesn’t tell you may hurt you. In the case above, the SDK could simply not declare using the Location permission and only exploit it should your app have it. All might be done behind the scenes, and worse – behind your back and on your watch.

Comply with Me

Specific types of mobile applications need to comply with certain regulations. The most known example is the COPPA (Children’s Online Privacy Protection Act) regulations which apply to any app designated for kids under the age of 13.   It requires parental consent for any collection of location data. Apparently, even a warning for not complying with these regulations can get apps pulled from the app store.

On December 2014, Google suspended all the apps that were developed by the Chinese company BabyBus. Google claimed they violated the COPPA regulations by collecting geolocation data from their users. The company attributed the data collection to “Android’s third-party statistics software plug-in.”

Using monitoring or analytics SDKs is very common. However, it is also very common for these types of SDKs to collect geolocation information, without any malicious intentions. But the combination of using such SDKs in apps targeting children makes it all the more risky, both in general and in terms of complying with regulations.

Bad News from BadNews

SDKs, which are integrated in your app, often access the server to read configuration or update resources. Downloading code dynamically is known to be an attack waiting to happen. It can be used to embed viruses or backdoors, as happened in the past with BadNews SDK. In short, BadNews’ ad-network (The name gives the ending away, don’t you think?) was integrated in more than 32 apps, with millions of downloads, when it was found to embed malwares on user devices and steal sensitive user data. Needless to say, Google removed all apps that used this SDK and suspended their developers’ account.

2. User Experience

Apart from security and privacy issues, SDKs might introduce major flaws in the app user experience. SDKs can cause functionally bugs, slow down your application or its launch time and cause excessive battery or data consumption. In a survey we conducted, 100% of the app developers reported they found functionality bugs when using SDKs.  And the ridiculously large numbers don’t stop there – 85% reported crashes caused by SDKs while 54% reported that SDKs slowed their app and damaged their performance. Think about it for a second – every single app developer we came across had to deal at one point or another with an SDK causing him or her bugs. Instead of saving precious time, these developers had to chase and deal with someone else’s buggy code (which as we all know, is without a doubt a developer’s most hated job description).

Talking to hundreds of app developers, it is not hard to realize that developers are extremely frustrated when integrating SDKs in order to expedite their development process that ultimately end up losing users over their real time behavior.

Let my App Go

One more issue which can be very frustrating for app developers is replacing SDKs in their already-installed apps. It applies to many cases, such as an app developer that isn’t receiving the service he expected from a tracking SDK. He would like to stop working with that SDK company. Yet he faces a problem: the app is already deployed, with millions of users using it. The developer is bound to this company until no device is running a version of the app with the SDK still within it, be it by updating the app to a new version or uninstalling it altogether. This may take a long time and in the meanwhile the developer pays a company that they are no longer satisfied with its services.


It’s no doubt that SDKs are a great asset for app developers. And it’s no coincidence that the usage of SDKs in the past year has at least tripled itself. The relationship between apps and SDKs is built on trust, yet sometimes trust can be broken. The app quality and security might be compromised as a result of this broken trust. Bubba Murarka from DFJ Venture described it well in his blog post as he talked about living in the “SDK Crunch”. We couldn’t agree more. Using so many SDKs in your app, as he says, is like drinking a poorly mixed drink: each ingredient is delicious on its own, but the same isn’t necessarily true when all are put together.

My goal here was not to share horror stories and discourage you from using SDKs, quite the contrary is true. Use as many SDKs as you need to create your wonderful app. Having said that, I hope I managed to shed some light and make you aware of the risks associated with using SDKs and the things to be on the lookout for. These risks are exactly the reason we decided to found SafeDK, but that’s a topic for another blog post.