Blog

Blog

Slimming Down: Fighting SDK Fatigue and Bloat

Posted Jun 2, 2016

SDK fatigue is real. Short for software development kits, SDK’s allow developers to create applications and other functions in an app without having to build them from scratch and are a critical part of the mobile industry. If it’s possible, there’s probably an SDK for it. With the wealth of code and asset libraries available to developers, it’s feasible that a developer could build an entirely new app and not have to write a single line of new code.

Unfortunately, too much of a good thing isn’t always better. More SDK integrations means more maintenance for developers and larger download sizers for users.

Games as an app category lead average SDK integration with 17.5 SDK’s per app, according to a report released by SafeDK. Having all those SDK integrations up and running can save time in the short run, but it’s also a lot of additional work for developers to keep updated and compatible, checking against every new version of an operating system, and so on.

Matchmaking? Pop in an SDK. Physics? An SDK. Over the air updates? There’s an SDK for that. Points programs? Need an SDK for that, too. Almost anything a developer might want to add to an app they don’t want to build from scratch can come in the form of an SDK.

The nine broad categories of SDK’s include analytics, advertising, social, payment, location, rewarded video, crash reporting, tracking, and marketing automation. All serve very specific functions and can all make an app bigger.

Slimming Down
17.5 SDK’s per app is a lot. At the top of the list, almost 90% of apps surveyed by SafeDK use an analytics SDK, followed by advertising at 80%. The drop off after that is to 55% with social. Marketing automation brings up the tail end at 7.5%.

In order to combat SDK fatigue, developers and publishers should look at replacing individual SDK’s with multi-function SDK’s that perform multiple operations. Advertising and marketing automation tools like Compass™ are coming together as a single SDK, greatly improving the tools available to publishers whilst still reducing the number of SDK integrations needed.

Crash reporting, analytics, and tracking services are often combined in a single SDK by some providers. Google and Apple have also increased the detail of crash and usage data for installed apps with each new mobile operating system update.

Planning ahead when building an app and choosing which SDK integrations to include before development hits full stride can also help to curb unnecessary SDK’s in an app. According to Dan Laughlin of HyperMX, ROI-based decision making, a centralized process for owning SDK integrations, and constant reevaluation can also keep integrations to those that are actually useful and necessary.

Keep it Lean
Like building a burrito step-by-step and then having trouble folding the tortilla at the end, it’s easy to let SDK’s get added over time and then look down at an app that’s larger than 100MB – Apple’s over-the-air download size limit, and the current maximum size for a Goole Play app. SDK fatigue or bloat should never be a factor in whether a user can download your app whenever they want.

Carefully assessing what SDK’s you’re using and judiciously picking the right ones for an app during the initial creation is way easier than going back and cutting later. Keep it lean and stick to the essentials to start – you can always add more in a later update.

Join the Conversation

How have you tackled the integration of multiple SDK’s and app download size? Tweet your thoughts to . For the latest AdColony mobile news and updates, follow  on Twitter, like us on Facebook, or connect on Linkedin.

Jonathan

An avid electronic entertainment connoisseur and huge pop-culture nerd. Jonathan uses his Swiss Army Knife of skills as AdColony's head of marketing and Senior Director — Global Marketing & Communications.
Jonathan

Latest posts by Jonathan (see all)

Latest at AdColony