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.
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 @AdColony. For the latest AdColony mobile news and updates, follow @AdColony on Twitter, like us on Facebook, or connect on Linkedin.
- The Article 17 Series Part 2: Privacy in 2020 – and beyond - May 26, 2020
- Leveling Up Hypercasual: Episode 1 - May 18, 2020
- The Article 17 Series Part 1: How Did We Get Here? - May 11, 2020