You know how some things were created to make our lives easier? The same has happened in the mobile development industry with SDKs. The growing use of SDKs has certainly made developers’ lives easier. They don’t need to spend time writing code and developing back-end stability for functionalities unrelated to the core of their apps.

According to our latest SDK trends report, a single app implements 17.6 SDKs on average, which means that mobile SDKs are popular today more than ever. But do we know all there is to know about the mobile SDK industry? Do we understand the potential and correctly estimate the risks?

While talking with many of our clients, prospects, and industry professionals, I noticed some major misconceptions regarding the use of SDKs.

Unfortunately having these misconceptions is a recipe for disaster – if you don’t know what some of your app’s code does, you could be subject to collateral damage. Therefore, I thought it was necessary to write this post and break some of these myths.

Myth 1: I know all the SDKs I have in my app

I recently spoke with a prospective client and asked him a simple question: How many SDKs are currently implemented in your app? He replied 6. I pulled up his app using our App X-Ray and discovered that the app actually had 28 SDKs implemented. Wow. The client was, of course, shocked.

I explained that this is very common. Sometimes you still have old SDKs compiling with the code, often you have big packages you don’t use in full (Google Play Services anyone?) and there are times someone at the end of the development food chain adds a library without informing the top of the pyramid.

Why should you even care? Well, first of all inactive to you doesn’t necessarily mean unused. SDK you no longer use may still be active in your app and if you dropped them due to bad user experience, you may have to rethink that. Also, you should care about the size of your app, both to download and how much space it takes on a user’s device. Since users care about these issues, you should care as well.

Myth 2: All my colleagues are using the same SDK and it works great for them, so no risk here

If I had a penny for every time I heard that one…

The biggest misconception here is that using the same SDK necessarily means using the same SDK version. And that’s just wrong.

SDKs constantly change versions of their product. Let’s suppose your colleague recommended a crash reporting SDK. Your colleague mentioned that it was the best crash reporting SDK he has ever worked with. But you happen to integrate a different version or the SDK behaves different due to your class structure, your build file or even build methodology. You could experience issues your colleague hadn’t experienced, and might never have.

Also, very important to distinguish between platforms. If your colleague gave you a recommendation based on iOS, for instance, don’t assume this means the same for Android and vice versa. And of course, distinguish between various versions of the SDK within the same platform – developing a native app is different than a cross-platform app (via Unity, PhoneGap, Xamarian etc.)

The essential point is: it’s important to use the SDKs that are right for you and your specific application.

SafeDK X-Ray: Find the SDKs Within!

Myth 3: I can easily remove an SDK, so there’s no real risk here

Wrong. And wrong again.

Assume you have had your app in the app store for some time now. You’ve had thousands of downloads. Suddenly, you decide to look at the reviews your users left you (which is a gold mine of data by the way, check out this post about how to run review mining). You notice a pattern of some bad reviews about the app crashing a lot or using excessive amount of battery. And here you knew absolutely nothing about it… Well, you investigate the issue and find out that it’s an SDK causing this.

Now what? Remove it of course and you’re done.

Well, you can’t just remove an SDK. You need to send a version update to the app store and wait for it to be approved, then published, and then enrolled to your active user base. That takes time.

In the meantime, the horror continues. By the time your iPhone version would get approved and your Android users would update (it’s not uncommon for users to get “stuck” with extremely old versions), they could experience this time and time again and perhaps won’t even bother coming back or updating when the update is available.

Needless to mention that the damage can be huge.

5 Myths of Using Mobile SDKs that Mobile Developers Must Know

The bottom line here is that it’s neither fast nor simple to remove SDKs from your app without first implementing a protective solution, like attempting to control the SDKs activity from your servers or using our In-App Solution or alike.

Myth 4: I’ve been running with this SDK for so long and it’s great, can’t do better!

Just because you didn’t have any problems with your SDKs up until now, doesn’t mean they won’t pop up later. The app’s ecosystem is very sensitive. With every app or OS update new issues may arise. For example, we found an SDK which worked great. Until we discovered that in the following version of the SDK it has accessed the location data three times more per minute compared to its previous version, meaning it consume much more battery. This is not the only situation in which a long-time SDK started misbehaving. Another such circumstance can happen when a new OS version is released into the market. SDKs that were compatible with the latest version are no longer compatible with the new one, which can also create performance or UX issues.  Compatibility issues are one of the main causes of app crashes.

So keep in mind that just because the app worked well in the past doesn’t mean it will keep doing it when things around it are constantly changing.

Myth 5: my user’s privacy is kept; I only ask for permissions that I REALLY need for my app code.

App stores have tightened the reins on mobile developers when it comes to transparency. It’s the case for when (and if) you include ads in your app and it’s the case when it comes to the permissions and privacy requests your app makes.

It’s boils down to this – once you’ve been granted a permission by the user so do your SDKs.

You’ve needed location and got it? Great. So did your third parties.

You’ve been granted access to the user’s accounts? Fantastic. Now your SDKs have that access too.

Your app is allowed to vibrate the device? Nice. But the libraries you use can do that too.

All of the above and much more are loopholes for privacy breaches. Ways for your SDKs to collect personal information on your users. Information you may not want them to have. Information whose collection by a third party is often required by the app store to be declared in your privacy policy. Are you sure you’re complying with that regulation? I’ve heard my fair share of apps complaining because they failed to inform about an SDK gathering personal information and causing apps to be rejected or suspended.

SafeDK In-App Protection

Myth Busters

Yes, SDKs are great and have definitely benefited the lives of mobile developers, we have seen this. However, it’s very important to know and understand all the facts when it comes to choosing and using SDKs.  Research shows that the misuse of an SDK or the use of a faulty one can be detrimental to the operation and success of your app. This is one of those times, where a little research and maintenance can help your app go a long way.

So use SDKs, but use them wisely. Select SDKs smartly and make sure you have all the knowledge and tools needed to manage them optimally, while keeping your apps’ UX, performance, and user data safe.