Mobile SDKs are, for most publishers, a necessary evil. Whether you’re trying to integrate analytics, cross-promotion, tracking, monetization or payments, your first step is most often to inject a third-party SDK into your codebase.
This much-maligned piece of software drives developers, operations and marketers alike up the wall — creating well-defined operational specs that often change to soiling your product code with unspecified external components.
Are SDKs quite the dirty word, though? Or are there steps we can take to make the integration better, more reliable, more transparent and more convenient for all parties involved?
Much of the tension stems from the fact that SDKs are binary, black boxes that go into your precious code. It’s large, on account of duplicating a ton of libraries inside the SDK, and it compiles only under certain environments that are compatible with the way the SDK itself was compiled.
If it crashes or has a bug, you’re left with trying to poll a support team or wading through incomplete documentation, and debugging someone else’s code in a black box is frustratingly difficult.
Rise Of The “No-SDK” Movement
Many of these problems could be remedied if we could access the same functionality needed without having to integrate a precompiled blob of code. One way of solving this is through the “no-SDK” offerings that are becoming increasingly popular.
In this instance, a much more simple web API is exposed for developers to integrate directly, or construct services based on systems that are likely already in your app.
The Rarified Air Of Open Source SDKs
Alternatively, companies are looking to go open source. Ultimately, the precompiled SDKs were, at one point, source code just like your app itself. If you could just integrate the plain source code, it’ll behave and compile natively into your app. With an open-sourced SDK, you’re working with code you could have written yourself, which you can understand by cracking open the hood and that will compile as a native part of your code.
If it’s so convenient for developers to integrate, why would a business decide to not open source their SDK?
Open-source SDKs do exist, but they are exceedingly rare. A quick look across the mobile ecosystem — tracking companies like AppsFlyer and Tune, analytics with Flurry and monetization with AdColony — shows that precompiled SDKs are by far the preferred choice. Among open-source SDKs, Segment.io stands, out as does Chartboost, and we decided to go this route from day one, as well.
Yet, if it’s so convenient for developers to integrate, why would a business decide to not open source their SDK? Why are precompiled SDKs so prevalent?
Dispelling The Fear Of Stolen Code
The most obvious answer that comes to my mind is that people are scared that when the source code is open source, someone will steal it and hence steal their business. The SDK is as much intellectual property as any other part of your codebase, so it’s not unintuitive.
It’s not a very good reason to avoid open sourcing your SDK, though, in most verticals. It would be true if the SDK was a standalone product on its own. Analytics and tracking require extensive and sophisticated back ends, with internal APIs communicating with a multitude of services and performing complex computations at very high speeds. Ad networks require ad servers, and a big line of advertiser clients.
Payment solutions put most of their efforts into ensuring back-end security and compliance with stringent regulations. Oh, yes, and you would need a data center. In a sense, the SDK is like a lightbulb that needs a power socket; certainly not the hardest part of the job to replicate. Sure, you could steal the source code of an SDK, but you’d still need to replicate the data center, the back ends, the APIs, the database and so on. The SDK itself is not a barrier to entry.
More Sinister Intentions?
Another reason why providers might be hesitant to go open source is that the SDK could potentially be altered. You can’t tamper with the code in a precompiled binary, which you could theoretically do given the actual source code. Again, this makes intuitive sense, but let’s dive into it a little.
With an analytics or tracking SDK, you could largely only affect your own dataset, for which you’re paying. Ad networks may have that knee-jerk reaction: What happens if a publisher alters the SDK to report false impressions and clicks? Advertisers today really care about installs and purchases, which clearly can’t be falsified with a modified publisher SDK.
In some sensitive types of systems, like payments, this could be a theoretical concern. A clever fraudster could perhaps more easily file false charges. Such a fraudster — crafty enough that they could avoid your other security layers and get enough users that it’d be profitable — probably wouldn’t be much deterred by the black box SDK, either. This minor and lazy security comes at the expense of the stability and reliability of everyone else’s integration.
Ultimately, while we may intuitively think there are good reasons to precompile an SDK, we see upon closer inspection that these ideas are distinctly shaky.
Behind Closed Doors
I struggle to see any other reason, except for one, to precompile your SDK: You don’t want other people to see your source code. At best, that means it’s badly written. At worst, that means it’s doing something that you don’t want anybody else to know about.
Without extensive investigation, you won’t be able to know exactly what the precompiled SDKs are up to in your app. It’s exceedingly easy to wire a binary black box SDK in such a way that you, as the developer, would never know what’s going on inside.
Not long ago, it was common wisdom that publisher SDKs from ad networks had a habit of looking for other SDKs in the app, and adjusting their CPC rates based on what other providers you had integrated.
Most people who build precompiled SDKs are not evil, nor plotting schemes behind your back.
Apple has fervently been locking down an API feature that allows apps to test deep-link URLs, which has been used by certain companies to find out what other apps are on a device. Because such data is highly valuable for ad targeting, this is a typical “feature” that could be — and to our consternation, has been — embedded in precompiled SDKs.
What happens when your app has additional permissions from the user to look at telephony settings or otherwise? In this case, a precompiled binary could completely opaquely poll those same system calls to collect additional data.
In particular, companies that monetize on targeting data may find very quickly that they can enrich their datasets through features that are not necessarily well-documented. In most cases, nobody would find out. This may not be the initial intention, but with flagging growth and investor pressure, it may be a dangerous temptation.
Now, most people who build precompiled SDKs are not evil, nor plotting schemes behind your back. Lacking malicious code, most of your providers do not have any valid reason to hide the source code of their SDK. Yet they do because it’s common, and because it appears wise at first glance.
If we were to increasingly insist that our providers provide their SDK as open source, we would be able to make significant strides in the transparency and openness of the systems we distribute to millions of app marketers, and billions of smartphone users, every day. Not to mention that you wouldn’t hear a peep from your engineers when you want to try out a new tool. Perhaps that time is now.