Evaluating and selecting the right SDK for your mobile app

Matthew D. Sarrel is a technology journalist, analyst and founder of Sarrel Group, a technical marketing consultancy based in New York City and San Francisco.

Anyone developing consumer software knows that we live in a mobile-first world. I see companies today that actually have a live app before they have a live website.

Earlier this year, a comScore report found that the majority of consumers are using a combination of PC/Mobile/Tablet to access retail sites. Just as we saw a revolutionary shift from traditional methods of interaction (snail mail, telephone) to Web in the 90s, this decade, we are seeing a shift from Web to mobile.

Consumers also prefer to use mobile apps over the mobile Web. The data shown below from Nielsen on mobile media time shows the consumer preference for mobile apps which account for 89 percent of media time in mobile vs. 11 percent spent on the mobile Web.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

Developers in the mobile-first world have to build great apps or they’ll never succeed. In order to offer a full baked app, developers have to rely on integrating SDKs with their applications.

An SDK powers specific functions within an app, yet its stability and performance is critical to the app’s stability and performance.  Think of an SDK as your app’s pacemaker. If the SDK stops, your app will crash.

This is why it is important to pick the best SDK to provide the features you need, preferably a battle-tested, mature one with a proven track record. After all, are you going to buy a no-name pacemaker or go to a Medtronic or Boston Scientific who are already powering thousands of hearts?

SDKs are everywhere

There are SDKs available to do everything from app prototyping and debugging, to user analytics, marketing tools, advertising tools, planning tools, and customer support. Developers can choose from a myriad of tools to monetize their apps, test, monitor app performance, manage security, study user behavior, cross-promote apps to attract and engage users, manage API use and simplify use of cloud services.

It’s been estimated that the average iOS app contains seven 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.

Venture capitalist Bubba Murarka wisely points out that “the problem is — how do all of these potentially interact with each other and with the app’s primary functionality? Third party libraries can slow apps down, cause crashes, or worst, maliciously steal user data.”

Developers need to be careful when selecting an SDK for inclusion in their app in order to avoid “unintended consequences.” Customers are going to blame slow performance, rapid battery drain, wasted expensive mobile bandwidth, and app crashes on the SDK.

There are a lot of factors to consider when selecting a mobile SDK such as size, CPU usage, network polling, stability, memory usage, and the SDK’s effect on battery life. Poorly optimized resource consumption in an SDK yields an app with inefficient resource utilization.

Android already tells users, and iOS’s next release will too, which apps are resource hogs. As it is, studies show that 90 percent of app users stop using an app within six months. App developers are already competing in a tough arena. The last thing they need is a poorly written SDK driving customers away from their app. Speed and application performance are a measure of quality to most users.

So who provides great SDKs?

The most widely adopted SDKs are pretty good examples of well written and useful code.

Flurry is an analytics SDK, which works like Google Analytics for mobile apps. It’s extremely popular. Developers use it to learn how people are using their apps and they also use it for advertising.

Until two years ago Flurry was a resource hog on CPU and caused a lot of app crashes. The company has since resolved this issue, and Flurry is the standard for advertising and analytics.

Crashlytics provides crash tracking and tells developers why the app crashes, how many devices it has crashed on, the other apps running at the time, and provides stack traces. A large number of consumer facing apps use Crashlytics – it is solid and efficient. 

This is a great example of a well-written SDK that is widely implemented because of its functionality, stability, and small size. It provides something that developers need with almost zero impact on the app itself.

Urban Airship provides a full suite of messaging and content delivery tools, including push notifications, rich media messaging, in-app purchases and subscriptions. It’s used by app developers to send push notifications to users.

On the Web, developers could contact users via email, but in the mobile world, this equivalent is the push notification. This makes Urban Airship a pretty important SDK for app developers; it’s a high quality SDK that’s small and compact, high quality, stable, and makes efficient use of resources.

Helpshift is a CRM SDK. Engagement with users in the mobile-first world takes place directly within apps and the Helpshift SDK experience is such that customers can get answers to common questions and ask questions on their own without ever leaving the app they are using.

Admob is Google’s SDK for advertising on mobile. It’s widely implemented because it provides functionality developers need for their app and it is compact and efficient.

Of course, these are just a few examples that are popular with developers in today’s industry. What else do you look for when selecting the right SDK for your app? Please share your thoughts in the comments below.