Why There's More To SDKs Than Meets The Eye

Sending.io chose the API-only approach instead of offering an SDK when working with mobile game developers. Sending.io's experience shows that using only an API can solve problems for startups serving mobile game companies that want to scale quickly.

Most mobile game solutions vendors provide an SDK that makes calls to their API.  This SDK code is integrated into the game app by the mobile game company, then the SDK interacts with the API according to its own logic.  Often, SDKs make calls to third party services, which are not under the control of the SDK provider.  This can add additional complexity and risk. 

An API-only approach means offering just an API, and then letting mobile game developers write their own native code to call that API.  This means that the mobile game company has complete control over how its app is operating. They can write their own Error Handling code for API calls.  There is no SDK operating outside of the control of the mobile game app.  This API-only approach is often favored because SDKs can create performance issues and introduce other risks when they are integrated into apps.

While it is necessary to integrate SDK code into your app for some kinds of functionality, many mobile game vendor solutions don't neessarily require you to work through their SDKs. Going direct to their APIs from your own code in your own app would be just fine. 


Sending.io provides email retention and monetization services for mobile games. The company created a robust Platform to deliver these services that operates separately from its clients' mobile apps. Monetization happens outside of your app, and you access the platform with simple API calls.

Sending.io says it only requires a few lines of code and less than an hour of work for a game developer to deploy a complete email retention program. Sending.io's API documentation explains its Integration requirements.

Amy Monier, Sending.io's vice president of business development, said the following at the LA Games Conference:

As a mobile app publisher, it seems that any product you want to use for analytics or advertising requires you to integrate an SDK. Most vendors who help you make money — like with video ads, banners and offer walls — all want you to integrate a different SDK. For a lot of mobile app publishers, they already have multiple SDKs running, and they have to worry how about many SDKs they can incorporate before they have "too many." There are other issues, like SDKs crashing your app, user privacy concerns and the difficulty of selling SDKs to mobile developers. Sending.io chose to utilize an API to integrate our rewards solution with our clients. We thought an API would be superior to an SDK, and our rapid growth proves we made the right decision.

Offering to provide more details about her API vs. SDK thinking, Monier told ProgrammableWeb the following: 

SDKs Can Break Your App!

SDKs crash. When that happens, your app often crashes as well. Your users will have no idea what is "breaking." Users are simply forced out of the app without warning. It is a bad User Experience for a user to get kicked out of an app. It's hard enough retaining users in the mobile app space with an app that is working well. Then you start working with a third party to help you monetize users, and that causes your app to start crashing … and people start uninstalling. Ouch.

If an API breaks, it doesn't usually affect the Front-end user experience. There may be things that pause in the back end, but a correctly coded app shouldn't crash if an API call is not returned.

SDKs Threaten User Privacy

Mobile app publishers often hesitate to work with a new SDK because of privacy concerns.

Third-party SDKs can collect valuable data about users without an app publisher's consent. Third-party SDK code embedded deep in an app's software makes Function calls, collects data and communicates with third-party servers. Who wants to audit mobile SDK code and have long conversations with SDK partners to figure out what is going on?

Even if the publisher gives consent for data collection, a lot of times end users are not informed of what SDKs are running in the background, what information is being collected on them and how it is being used. These open both the SDK owner and the app publishers to legal liability and require disclosure. User tracking, data collection and online privacy are increasingly big concerns for lawmakers and users.

Sending.io decided to help limit both parties' legal risk by using an API, not an SDK. The only data Sending.io collects comes transparently and directly from the publishers via an API. Mobile app companies never have to worry about what data Sending.io is collecting, because they are the ones sending it to the Sending.io API. Sending.io, in turn, worries less about the legality of the data it is collecting because publishers explicitly decided to send it to the company.

SDKs Are a Hard Sell

SDK integration is tough to sell. Mobile app developers get pitched by SDK providers constantly. Most developers have had some painful experiences integrating SDKs. Mobile app companies often tune out when they hear about the next “super-lightweight SDK” that will solve all their business problems.

Sending.io realized early on how difficult an "SDK" sale is in the mobile apps market. It quickly decided to roll its rewards program out using a solution that requires only two API integrations.

Sending.io found that developers and publishers are much more receptive to incorporating an API into their apps, rather than “yet another SDK."

Sending.io believes its API approach enabled it to secure more clients faster, and helps the company ramp up each rewards program quicker.

APIs Are Multiplatform

Sending.io became platform-agnostic when it eliminated the need for an SDK in its product. It doesn't have to build different SDKs in native code for each mobile OS that its clients use. Multiplatform app publishers simply call the same API, regardless of what native code is used to write that game.

The mobile game community may be able to solve a lot of problems caused by SDKs by focusing on how Web services APIs can best be used to serve the needs of mobile game developers.

Be sure to read the next Games article: Daily API RoundUp: Internet Game Database, Mozilla Canvas, BlockCypher