[Originally posted on PocketGamer.biz August 24th 2013]
Software Development Kits have become something of a Frankenstein’s Monster in the mobile development community.
They were created as a means to enhance our apps but are actually becoming a huge problem.
If you need to add anything from analytics to an offer wall, there’s probably an SDK for that.
By just adding some code, there’s plenty of ways to optimize your app. However, at what cost do these SDKs come?
When SDKs begin to bloat your app it can increase the chances of bugs and crashes, drain your engineering resources, and hurts the user experience in your app.
Something for everything
This is just how bad the SDK bloat issue has gotten. There’s an SDK for analytics, an SDK for A/B testing, an SDK for display ads, and a direct deal ad network and/or mediation provider.
Then you have an SDK for a video ad network. Then an SDK for an offer wall provider. Once the app is making money, developers can put another SDK in to help provide user acquisition insights.
SDK bloating has become such an issue that some apps actually have more lines of code for the SDKs than for the actual core content of the game.
One of the biggest problems that comes along with SDK bloat is the time and resources it takes to integrate and maintain them. The more SDKs that go into the app, the more that engineering resources you have to be set aside for keeping them up-to-date.
For developer operations of any size, engineering resources are a precious thing and every minute spent away from creating awesome content hurts the business.
Beyond lost time, multiple SDKs bring about an increased potential for bugs.
As any developer knows, coding can be a tricky mistress. By adding additional lines of code, you increase the risk for things to go wrong – ending in bugs and potentially crashes. When you also consider that the code isn’t coming from your team, you can’t be sure how it will get along with your content. This is multiplied when you also have different SDKs interacting with each other inside your game.
This whole issue reminds me of my own personal addiction with buying gadgets.
I started off with a PC laptop. Then I bought a Galaxy Nexus phone. Next came the iPad 1, 2, and 3. After that I picked up the Kindle Fire and Nexus 7. Of course I had to see what the iPad Mini was all about.
Then wearable gadgets came along so I grabbed a Garmin watch and FitBit. But then the iPhone 5 came out so I made the switch over to iOS. After everything, what I ended up with is a bloated briefcase that nearly burst at the seams with over a dozen gadgets.
Guess how many I actually use in a day? Two. A single laptop and my iPhone. All the rest rarely come out of the bag.
So what can developers do?
Start by finding a one-stop-shop SDK, like NativeX, that provides a competitive feature set encompassing 90 percent of your needs. Ideally, that one SDK should be able to do rich media, video, interstitials, offer walls, and also act as a mediation layer with other ad networks.
From there, developers need to ask themselves how much value they’re really getting from each third-party SDK and add sparingly.
I finally made the decision to un-bloat the briefcase and only carry the two gadgets that do a majority of what I actually need. Developers need to make a similar choice and slim down to only the SDKs that offer what they need with the least amount of bloat.