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:
-
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.
-
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.
-
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.
bubba.vc 
We had 3 SDKs in our app
– one for beta testing + crash analytics (incidentally, it caused some crashes itself! in our production app.)
– Facebook SDK
– one for analytics (mixpanel)
We also used 2 third party libraries – AFNetworking & one for XMPP
We definitely see the SDK crunch in the PhoneGap ecosystem. Push notifications, ads and analytics are huge.
I like the approach of folks like segment.io in the near term but ultimately there’s a big opportunity for companies with broad services like Adobe or Google as well as the bigger startups like Flurry.
We actually experimented with the “in app web services” thing with PhoneGap a while back but shelved it.
There is another way of looking at “SDK Fatigue”: “wrapping other SDK’s functionalities into one” can be done in an analogous way to what segment.io does on the web.
But our approach is to provide a reason to do this – crash reports, app-ratings, push handling/analytics are all components of a user-segmentation and user-lifecycle model.
i.e
1. Users who’ve had crashes are a segment that can be surveyed or targeted for an “please upgrade” campaign.
2. Highly engaged users are probably the best to ask for an App/Play store recommendation. (Instead of spamming people every 5 times they open the app).
So the current situation has grown out of an MVP approach to startups. There WILL be consolidation but also around cohesive value rather than just some acquisition rollup.
cheers
d.
It seems you are combining two fairly different things within this post. Direct communication between apps on the phone and SDKs to provide native code to communicate with external APIs from various services. All our experience has been with SDKs for communicating with external APIs.
The new mobile application we’re working on already has dependencies on 3 SDKs.
I’m curious how you see this as that different from leveraging 3rd party SDKs in web server code.
I think there is a large class of external web based APIs that could be handled clientside by the API owners’s native app with better results for all involved. For instance, no need to get all facebook friend list data from server when local facebook app already has it downloaded. This reduces data downloaded, server load and duplicate work around things like data cacheing which means less bugs / crashes. Win for developers, platform owners and end users.
In scenario 3, do you think that a widely adopted open source standard or library (e.g. jQuery on the web) could serve as the single middleware SDK between the mobile app and all other web-based SDKs? Do you know of any attempts to date?
I was thinking of something more crafty that used local loop back on the device to pass data between APIs. Wouldn’t work for UI needs though. Don’t know of any attempts to either concept though but haven’t looked that hard.
Coming at this from the adtech angle the mediation platforms have tried to mitigate the exposure to multiple ad network SDKs by requiring server-side integration from the smaller ad networks and wrapping the SDKs of the larger folks (iAd, Millennial, etc.) in their own. Eventually I would imagine mobile evolving to where desktop web is now with Tag Management platforms proliferating to manage all the calls from a single API call, but it will require pressure from large media companies and app developers to make this happen.
Great post. This is exactly what we’re solving for at mParticle. What manifests itself as a resource issue is actually a data issue. Ultimately data collection and data distribution need to be 2 distinct activities with proper workflow to ensure privacy controls in between. And wrapping SDKs is a weak solution that doesn’t actually address many of the in intended consequences of the given setup (integrated end points)
we should connect.
Of the major 4-5 mobile apps I manage, we have about 8-10 SDKs. Additionally, we have international versions of our app, but our 3rd party developer used the same code base and baked in those SDKs (mainly for ad serving) so one app had upwards of 11-12 SDKs. Now, aside from all of the issues that could arise from this, the one that impacted me most from a business standpoint was SDK maintenance. Two times when submitting an app update to Apple, it was rejected for use of improper APIs or Identifiers… Long story short, we had older SDKs still in our app that weren’t even being used, and therefore caused our rejection and subsequently pushed back our release date and business deadline to go live with our update.
So I of course appreciate the security side of things, but from a business ops standpoint, just having so many SDK’s has resulted in us missing business deadlines.
Gene, great point that I failed to highlight enough in my post. The reason for The Mobile SDK Crunch mattering now is that it is affecting business and product decisions. Especially as more and more marketing becomes code driven.
Hi Bubba
i was at first row when you mentioned that “SDK crunch” thing. Cool meme. maybe it will make Techmeme one day
right now there is no better solution and i don t see any good one anytime soon. There is a minimum number of SDK you need to run your apps. Analytics, Attribution, Social connects, Private testing. Just with that you re already at 4/5 SDKs.
You can t decently run a business as an app developer without those, unless you believe is some sort of “artistic way of life”…
For ads any thing that is not run in a natively coded SDK will end up looking or acting like crap. This is why 90% of ad SDK and networks look so terrible. They are wrapping “web experiences” with no attention to the user experience. Results: it s damaging a lot more than the way the app is behaving. It s damaging the user experience.
Facebook has nailed it. on Facebook with elegantly integrated ads which look good and loads fast and perform well.
We believe that in that space in particular there is no better solution for now. Even running via mediation platforms is not good enough, in particular when it comes to targetting and attribution.
Bottom line: there is probably a crunch, but app developer have to learn how to deal with it because it ain’t gonna change any time soon
Ouriel Ohayon
http://appsfire.com
ps: our SDK run on over 2000 apps. i am talking by experience too
It’s not uncommon to see apps with 20+ SDKs inside of them. Here are three top tier apps where this is the case, and they were the first three I looked up:
http://cl.ly/image/1Z3r1M0J2K20
I’ve seen apps that have up to ☢ 40 SDKs ☢ (maybe more) within them.
Pretty amazing the above apps can maintain such stability and high ratings despite all the moving pieces.
Belatedly joining the conversation here. As the originator of the question at the conference, I am very interested in seeing where this one goes and participating in future discussions on the topic should they happen. Totally agree that there an opportunity for someone to offer SDK optimizations, management and installation as a service. Apportable is doing integrations for android, one wonders if they might be looking at bigger opportunities? Google is looking hard at their app store and how it intersects with their advertising products as well I understand. With Apple potentially announcing the long awaited arrival of iOS and apps and games on Apple TV tomorrow one would imagine this conversation is going to heat up quite a bit in the coming months.
Thanks for the great insights at the excellent InContext conference.
What about SDKs that increase developer productivity ? We are using dozen of tiny libraries that help to quickly solve common programming tasks such as: json and other data format processing, ui patterns, protocol implementations. Most of those libraries are open source. Code quality is not always on the top level and sometimes we experience memory leaks, crashes and performance issues. Usually we just go and fix found issues in the source code or ask community for the help. Concerning privacy issues, I think it’s almost not applicable to the open source SDKs, provided developers review code of the SDKs.
We use a similar notion to the SDK crunch – calling it the rise of the Mega SDKs. We ‘ve been tracking the consolidation of SDK startups through M&As – see the mid-2013 landscape here:
http://www.developereconomics.com/rise-of-the-mega-sdk-vendors-in-mobile/
Evaluating and selecting the right SDK for your mobile app | vienergie