This is a guest post by Orly Shoavi from SafeDK

Being in the mobile app industry can be quite tiring, I know. We’re all tired of juggling so many things in the air, whether we’re app developers, app publishers or marketers.

The fast-growing pace of the industry leaves us no choice but to constantly adapt and evolve, or just fall. Lovely.

One of the “easy” ways to adapt, is to take on SDKs, and a lot of them (17.81 on average, according to SafeDK’s latest report).

Why? SDKs add huge capabilities and features we all need in order to keep up, without the need to proactively develop them internally. Capabilities such as analytics, communication, monetization and so on.  So far, so good.

Well yes, true… it’s part of the logistics. But you can’t very well leave over 17 pieces of 3rd party code unattended, can you?

Do you?

Most of us out there, either unconsciously decide not to manage SDKs (bury our heads in the sand) or consciously push back new SDKs and end up falling behind of our competitors. And that, friends, is called the ‘SDK Fatigue’.

What exactly is the ‘SDK fatigue’?

Well, a lot of work is needed to keep SDKs updated and compatible, testing and checking them against every new version of an operating system, and monitoring their behavior.  This causes SDK fatigue, which has dangerous implication on the app’s development, product and marketing operations.

Let’s see what can happen…

Curtain number 1– Mismanaging our SDKs

Not managing our SDKs properly might be very harmful. It means that we don’t proactively invest in analyzing and monitoring the SDKs behavior and implications on our app performance and user data.

It leaves our app vulnerable to “bad” SDKs that may contain viruses or malwares, and SDKs that can cause crashes, slowness, battery drain and privacy issues (piggy-back your app permissions to access your users’ private data for example) and so forth.

The consequences are poor performance, dissatisfied users, uninstalls and in rare cases it can even lead to the app getting banned from Google Play or the iTunes store due to violations.

Here are some real examples of SDKs causing apps to get banned, that were covered by the media:

• Hundreds of apps have been banned from Apple’s App Store for spying on your personal information (Business Insider)
• Hundreds Of Apps Banned From App Store For Accessing Users’ Personal Information (Techcrunch)

O.K, I’ll take what’s behind curtain number 2 – giving up on SDKs

Some app developers who are aware of the risks, choose to be very conservative with implementing more SDKs. They are reluctant to add external code to the app. They therefore define such wiring evaluation and implementation processes, that their product and marketing teams simply wait forever, before they can work with the tool they need.

I don’t think that the phrase ‘better safe than sorry’ proves itself true in this case.

There are SDK categories that you can’t live without. Period. Here’s a nice article about the SDK categories that every product manager or developer needs.

Compromising your app richness and innovation, by saying NO to advanced capabilities, will result in you staying behind and putting your app success at risk. You see, new SDKs = new set of features that are probably much more innovative compared to traditional tools. Basic evolution, you know…

What’s behind curtain number 3?

As necessity is the mother of invention, new work methods and solutions were developed to help app developers deal with the SDK fatigue.

Top developers who knew that they couldn’t risk their business, made sure they can easily implement SDKs as needed. But, on the other hand, they had to keep their apps performance and user privacy intact. So, App developers developed great techniques to handle multiple SDKs. Here are some tips.

1. Explore which SDKs other app companies are integrating

Sometimes the best way to make a decision is by copying what others have done well. I tend to trust an SDK more if a bunch of my colleagues have been using it and are satisfied. I am also happy if I learn that some respectable app players have been using this specific SDK.

I’m sure that you have a list of competitors or similar apps you use, for different purposes, so why not use it for determining which SDKs you should use?

We’ve developed what we call the App SDK X-Ray tool that offers developers the possibility to search for an app name (may it be a competitor or a similar app) and find out exactly what SDKs they are using. It is free to use for up to 5 searches. Please note that it’s only relevant for Android apps.

This tool will allow you to search for a specific app and see what SDKs are implemented.

2. Investigate the SDKs you integrate with your app, define the implementation process

Check those SDKs prior to integration. There’s a lot of information out there regarding SDKs, you just need to keep an eye out. There are quite a few SDK marketplaces that can help you overview implementation code, check on user reviews and more.

I would also recommend to implement SDKs first in the test environment, before you roll it in to production. Fight the SDK fatigue by defining an efficient process:

1. Ask the team member who requested to implement an SDK to run initial research (download the code, explore which known apps or colleagues are using this SDK, provide details about the SDK team, company location and alike) and then hand you the information organized.
2. Ask them to always ask for 2-3 similar alternatives (different SDKs, same functionality)
3. Have the SDKs implemented in the test environment and measure behavior.
4. Run AB testing on 2 similar SDKs, still in the same test environment, so you can easily select the best performing SDK (an SDK that does not slow your app, add to the start time, cause crashes and asks for too many permissions).

Use dedicated SDK management solutions

With multiple SDKs you are bound to run in to some trouble. Moreover, you must constantly monitor any 3rd party code that is in your app, especially if your app is your business.  You can’t afford to have an SDK crashing your app, adding significant time to your app start or accessing unnecessary private user data.

Moreover, you must find ways to respond in real time and be able to shut off a disturbing SDK without waiting until a new version is published and embraced by the user base. SafeDK does exactly that.

Final words

Always ask what’s behind curtain number 3. Things have changed and there are new ways to help us, people of the mobile app industry.

Do you remember back in the day when mobile advertising just started? We had to manage it all manually. But then hundreds of different ad networks popped up. Tracking became unbearable and then, voila, mobile app attribution tools came to the aid.

Same here. We used to have fewer SDKs, now there are thousands. Mobile SDKs management tools and smart processes are here to help.

Just make sure to fight ‘the SDK fatigue’ and more importantly, make sure to win.

About the author

Orly Shoavi – Co-founder and CEO at SafeDK, focused her entire career on the mobile industry. Orly held leading positions in R&D, Product Management and Business Development at companies like Intel, Radvision, modu and Telmap.

• Author
• Recent Posts

Guest Expert

This article was written by one of our awesome Guest Experts. We really appreciate the time and knowledge that they share with the app marketing community in our guest posts.

Latest posts by Guest Expert (see all)

• Engage, Retain, Earn: Growth Strategy for Game Apps [Based on Data] - 15 September 2022
• How to do App Store Optimization step-by-step: a full cycle of ASO in the App Store and Google Play - 9 August 2022
• The Importance of A/B Testing - 13 January 2022