A deep look into software development kits (SDKs)

Developers rely on software development kits (SKDs), that provide pre-made code blocks for integrating features like analytics and social network integration to enhance the gaming experience. In this article, Ilya Utemov, COO at ZiMAD, answers common questions about SDK integrations and highlights potential challenges faced by aspiring developers.
stock photo that conceptually symbolizes software development kits.

Mobile games have evolved into an industry with a turnover of billions of dollars, and millions of people play games on their smartphones and tablets daily. To provide the users with the best gaming experience, developers use software development kits to integrate various features and solutions into their games. Such SDKs are ready-made code blocks that can be used to add certain functions like analytics or social network integration into your project. SDKs often help make games more effective and profitable. In this article, Ilya Utemov, Chief Operating Officer at ZiMAD, answers the most popular questions about SDK integrations for those who consider using them and also tells about the pitfalls that aspiring developers may stumble upon.

What is an SDK and what are its functions?

An SDK is a software development kit, which consists of (in mobile development) a block of compiled code and resources (images, sounds, and animation) and performs certain functions. For a developer, it’s usually a black box that gets connected to the project and offers new opportunities. You can think of it as a module that you can add to your application. In theory, an SDK can perform any function you need and even include an additional game inside, but in reality, they are frequently used for working with specific services. For example, an SDK of any MMP platform provides functions for working with this platform, and an advertising SDK is used for working with ads from a specific supplier.

The most popular SDKs are Appsflyer/Adjust, Firebase, Google Ads, In-app, and Facebook/Meta Audience Network.

How is an SDK integrated into a mobile game?

First of all, the developer must decide whether they really need the functions of an SDK they have selected. It should be considered that every SDK has a negative impact on the size of the app — sometimes, integrating a couple of harmless SDKs can easily expand the game’s size by 20-30%, which also affects its performance on the user’s device. An SDK can bring unwanted permission requests that will frustrate users (for instance, we came across SDKs that required location access, which was quite unusual for their functions). It’s also worth mentioning that SDKs are written by people and can have errors (however, the majority of popular SDKs are quite stable). If you still decide you need them, there are two ways for how the process can go.

If we are talking about a single-platform app (for example, when a game is developed for Android/iOS using their branded platform environments like AndroidStudio/XCode), the integration comes down to including an SDK into the app. And in case with an app developed using a cross-platform engine (Cordova, Flutter, Unity, Unreal), the SDK integration is almost always centered around integrationing a certain package that includes SDKs for each of the target platforms. At the same time, there are cases when a package contains SDKs for Android/iOS, but not for Xbox, for example. So when using cross-platform development environments, it’s important to make sure that the SDK you need is not only available for your environment but also for your target platform.

What SDKs are most frequently used in mobile game development?

The most popular ones are SDKs for working with various analytical systems, MMP, in-game purchases, and advertising SDKs. In general, there can easily be dozens of different SDKs in a modern game.

Is it possible to use an SDK created for one platform for another platform?

Most frequently, no. If there’s no SDK for Android, you can’t just use the SDK for Windows. However, there are some good exceptions. For example, if an SDK is claimed to be compatible with Android, it is very likely to be also compatible with other Android-based platforms like Amazon or Huawei. Nevertheless, it’s important to stay realistic and figure out if the SDK will correctly operate on the platform you integrate it into. For instance, an SDK that works with GooglePlay payments won’t work on an Amazon device without Google Play, but an advertising SDK that can show ads on Android devices with Google Play will probably work on an Android device with Huawei.

The first problem you may face in any integration and support process is represented by technical issues. An SDK is often a black box, and its internal work is hidden from us, publishers. There are usually many SDKs in a project, and they are closely connected with each other by dependencies. There are special systems that help developers support such connections up-to-date (which is a must-have for development).

If we skip the technical part, the most frequent problem will be overhead expenses. You need to estimate the advantage of having an SDK in your app and compare it to the overhead expenses it causes. And this is only a small part of what you have to consider when making the decision to work with a certain SDK as an SDK is often a part of an external service, the necessity of which must also be evaluated by the publisher.

Let’s say, we have a game. And we decide that we need to update a certain SDK because the new version promises new great features. It turns out updating this SDK requires the project to have an updated service library, which, in its turn, is used by ten other SDKs in the project. After resolving the dependencies (in simple terms, selecting SDK versions and libraries that “fit” all the SDKs of the project), we find out that we can’t update just one SDK — we have to update all ten of them. And this is a completely different volume of changes and testing.

One more example is adding a new advertising SDK. Testing shows no issues, and the version gets sent into production. When releasing it for all users, it turns out that this SDK causes app crashes upon certain conditions (for example, a specific device model, an OS version, or even GEO). And we have to decide either to roll back the released version or try to selectively disable this SDK for the users with problems. We also must notify the SDK developer about these issues.

Can you give an example of how you adapted an SDK for specific project requirements?

The ready-made SDKs usually come in the compiled state, making the changes impossible, too complicated and unreasonably expensive from the production and development point of view, or even directly prohibited by the policy of the company that owns the SDK. In the majority of cases, the only way to introduce changes to an SDK is through communicating with the supplier of this SDK. However, there were cases in our experience when an SDK supported the Android/iOS platforms but didn’t support Unity used in our game. And we had to gather a small team of Unity and Android developers and create our own package that would let us use an Android SDK for Unity. That was how we didn’t change the SDK, but made an “adapter” for the required engine. It wasn’t an easy task, but it definitely worked.

How do you assess the performance and effectiveness of an SDK after the integration?

We usually consider if the goal for which we performed SDK integration has been achieved or not. For instance, we once integrated branded advertising, showing which was traditionally done through an SDK, into our project. After integrating, testing, and releasing it, we found out that the revenue from such ads was very small while the crash rate and performance indicators significantly worsened. It was impossible to solve this problem through the company that created this SDK, so we changed the provider of the branded ads. As a result, the crash rate and performance indicators came back to the pre-integration level (meaning we didn’t observe any technical problems in the game after the SDK integration), and the revenue from ads considerably increased thanks to the branded advertising.

SDK starter kit for aspiring developers

Speaking of must-have SDKs, you should, first of all, consider in-app SDKs like Unity In-App, which will let you as a developer work with in-game purchases. Then, you need to take care of analytics, and Firebase SDK will be just fine for that. If you plan to purchase traffic for your application, you’ll also need Appsflyer/Adjust SDK (traffic attribution services). And, of course, if you’re interested in getting profit from ads, you’ll need mediation and ad SDKs like Google Ads, Ironsource, MAX, or Facebook. I can recommend not to get overwhelmed with different SDKs, but to start small and get the bare minimum required for the work of your app.

Leave a Reply

Your email address will not be published. Required fields are marked *