The Mobile SDK Crunch

A few weeks ago, at InContext (organized by DFJ portfolio company Everything.me) in San Francisco, I participated on a VC funding panel discussing trends in mobile apps, contextual experiences, and the market for investing in mobile apps. Toward the end of the panel I blurted out the phrase “The SDK Crunch”, which made it to Twitter and started to spread. Yay, another mobile catch phrase!  Just kidding.  However, I’ve been thinking about this a lot since then because of the number of mobile startups I’m seeing that require an SDK and partly because of my time at Facebook, a company which has one of the most widely used mobile SDKs. 

Let’s briefly unpack the term SDK: By definition, an SDK is how applications can integrate functionality from another app or service.  There can be several ways apps can integrate with third parties but the most prevalent, on mobile, involves including code libraries from third parties into your app. The other common way is through APIs that don’t require third party code to be included in your app, but does require the you to understand the third party’s offerings intimately & keep in sync with their development roadmap.

Mobile platforms — iOS specifically — introduced new challenges with respect to application integrations because there’s no way for an app to provide an API to another app on Apple’s platform. This is the case because Apple optimized for protecting user’s security, battery life, and a host of other reasons, but from an interoperability standpoint, the architecture is constraining. Additionally, because of the velocity of app development and iteration, more and more supporting infrastructure, such as a/b testing & push notifications, is powered by third parties. This has resulted in two things: (1) application integration through web services, which require the device to use more data while also being beholden to a 3rd party’s uptime; and (2) the explosion of SDKs that rely on inclusion of a code library being used on mobile platforms.

Houston, we have a problem.

The best analogy I can think of here is a mixed drink. It’s pretty hard to make a bad drink if you only mix one or two ingredients: Gin and Tonic, Rum and Coke, Vodka Martinis, and so forth. As one adds more ingredients to a drink, the more likely it is to end badly for the drink itself (in the case of a Bourbon Treat) or for the drinker in the case of a Long Island Iced Tea.

Wagering a guess, I’d say 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. 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.

There isn’t a clear solution for this problem in mobile though. However it is is clear to me that is becoming a point of friction for new mobile services that require their customers to add yet another SDK’s client library. This means that SDKs currently deployed have additional value if they’re widely adopted. On the web this also happened but I think the effect will be amplified on mobile because apps are installed on individual phones not on a company’s servers so installations are “stickier”.  Also, for a variety of technical reasons, including a third party’s SDK on the web was never totally necessary (If there is interest in diving into this I can via the comments.)

Going to market with a new SDK is competitive, and in a competitive situation, differentiation is critical. Here, an SDK provider may elect to position themselves to replace one more or more existing solution (including wrapping other SDK’s functionalities into one) versus trying to earn a new slot in the app’s code base. Another tactic would be to open-source the SDK to all customers so they could examine the code during crash debugging. There could even be a standalone startup that just does an integration of SDKs into a single open-source solution.

Stepping back and looking at the macro situation, this all likely evolves into one of these end states:

  1. Mobile platforms create a better answer for integration between apps. Apple has started to do this with its integration of Facebook and Twitter into the iOS platform APIs while Android has a wild west approach that actually allows too much freedom from a security perspective.

  2. SDK consolidation happens through widely-adopted incumbents like Flurry acquiring SDK players and expanding their SDK functionality in a “one SDK to rule them all” type strategy. This process becomes a pendulum that is constantly swinging between exploration and consolidation.

  3. A new application-integration model emerges for mobile. This is the hardest to envision but one crazy idea would be to convert integrations to pure web service calls that don’t leave the device (this is actually an old idea). This limits integrations in several ways but I suspect they can all be worked out.

As a next step, I’d love to get a data driven discussion going. Please leave a comment with the number of SDKs in your app, if this has caused any major issues (technical, product or business) for your company and how your company is thinking of addressing this.