Software Development Kits allow developers to extend the functionality of their app or game via a software library. There is now a plethora of SDKs available for developers.
However, there is one major problem: SDKs suck.
This is because:
- They can break the app or game if there’s a bug
- They can slow down development because the integration requires vigorous testing
- They have to be maintained with constant updates and then tested again
The vast numbers of SDKs that developers have to integrate are giving developers “SDK fatigue” and making it harder for third-party service providers to get their service into apps and games, whilst taking away from game developers’ valuable time and resources.
The “SDK Crunch” is Upon Us
Bubba Murarka, a partner at venture capital firm DFJ, coined the phrase ‘SDK Crunch’ and guesses that “the average mobile app on iOS contains at least seven (7) third-party code libraries: analytics (often multiple), ad serving (networks, meditation, offerwalls, video, etc.) A/B testing, leaderboards, performance measurement, push notifications, Facebook, Twitter, PhoneGap/Titanium/Sencha etc”.
It would appear Muraka’s estimate is on point; SourceDNA analyses the SDKs that several popular apps use and has determined that:
- Sonic Dash uses 16 SDKs
- Deer Hunter uses 14 SDKs
- Agar.io uses 13 SDKs
- Angry Birds 2 uses 12 SDKs
- Subway Surfers uses 10 SDKs
- Pac-Man 256 uses 7 SDKs
The games listed here are backed by publishers and studios with deep pockets, and have the resources to integrate and test all these SDKs. But for most other developers, integrating this number of SDKs would cause a strain on development.
There are some services that are attempting to provide a unified interface for multiple third-party services which allow developers to install pre-certified third-party software development kits into their games through a single, unified SDK. However, the issue is that this only includes a limit subset of approved vendors, and of course, still involves integrating an SDK.
Other services provide an API that the developer can tap into directly. This can provide greater flexibility than an SDK, but it can take longer as custom code must be written to communicate with an API versus integrating an SDK, and it requires a deep understanding of the vendor’s technology.
Why HTML5 is the Cure
Developers could start using webviews to add extra functionality to their game without integrating an SDK. This relies on two key technologies:
- HTML5: easily handles animation, file and network operations, touch events, and much more
Goodbye SDKs, Hello SDK-less
My company Giftgaming actually decided to no longer maintain all our SDKs. This saves us time and money as we don't have to maintain SDKs across several different platforms, but we also save our clients time and money as they don't have to deal with the problems normally associated with SDKs.
For an advertising vendor, developers could simply provide an API key, along with the width and height of their webview, and then the largest ad that could fit into the webview could be rendered accordingly. With Giftgaming’s sponsored in-game gifts, a developer need only navigate their webview to a URL, and this will cause a sponsored gift to render. Once the webview has loaded, the developer can then easily call some code to increment currency, give an extra life, and so forth.
There are several benefits to an HTML5-based SDK-less technology, including:
- Very easy integration as only a Webview needs to be created
- Saves time for both vendor and developer as updates can be done server-side
Vendors should look to migrate their SDKs to HTML5 and go SDKless where possible, whilst developers should demand that more vendors go SDKless.
Nick Hatter is an independent developer and CEO of alternative monetisation firm Giftgaming.