This is a multi-part blog series on mobile SDKs. I’ll describe mobile SDKs from a comprehensive standpoint and answer all the burning questions you might have about mobile SDKs, including:
- What are mobile SDKs, how are they used, why do people create them, and why are they important to the mobile economy?
- Common use cases for SDKs in mobile apps
- How are SDKs implemented in mobile apps?
- Platform and Framework limitations and other challenges developers face when implementing mobile SDKs
- Hidden costs of manually implementing and updating mobile SDKs in apps.
- What are the security considerations of implementing SDKs
- New and Automated ways to accelerate implementations via automation that accelerate their usage and eliminate unnecessary work
What is a Mobile SDK?
A mobile software development kit (SDK) is a set of software development tools developers use and implement to deliver new 3rd party capabilities in a mobile application using the service provider’s published APIs. The traditional method for implementing a mobile SDK requires mobile developers to modify the app’s source code according to the instructions provided by a third-party service provider (aka the “SDK provider”). I will refer to this process as ‘manual’ SDK implementation — because in order to successfully deliver the new service in the app, one or more mobile developers needs to modify the app’s source code line by line or ‘by hand’.
SDKs are created and published by companies of all sizes, from Silicon Valley start-ups to major companies like Facebook, Amazon, Google, Microsoft and Alibaba — for services covering backend infrastructure, mobile advertising, mobile payments, mobile app security, and everything in between.
For the sake of simplicity, we’ll refer to them all as “SDK providers”. These organizations create SDKs and target them at mobile developers and app publishers, who integrate the SDK into the source code of an existing mobile app during the app development process.
There are thousands of mobile SDKs (16,842 according to Programmable Web).
Every app on the planet contains SDKs, and they play a critical role in how apps function. The SDK analytics firm SafeDK publishes a semi-annual report on SDKs, and for the past several years, the average number of SDKs for B2C apps (i.e.: “Consumer apps”) has hovered right around 18.2 SDKs per app. For B2E apps (i.e.: ‘Enterprise’ apps), it’s around 12 SDKs per app. For those of you wondering why consumer apps have more SDKs than enterprise apps, just follow the money. The consumer apps are typically free to download and monetize through ads and in-app payments. Both of those require — you guessed it! — SDKs.
SDKs Are Everywhere
Stating that a ‘mobile app’ is a collection of third-party SDKs and APIs packaged together with the app’s business logic is no exaggeration. Just about every task you’ve ever completed in a mobile app was enabled by an SDK, either directly or indirectly. There are limitless SDK categories, including SDKs for authentication, single sign-on (SSO), MFA, app management and distribution, app performance, analytics, messaging, conversational chatbots, data encryption, marketing automation, engagement, surveys, mobile ads, payments, and much more.
You interact with SDKs every day, whether you know it or not. SDKs are behind the scenes when you order a latte from Starbucks, deposit a check using your bank’s mobile app, pay a buddy using Venmo, search for a restaurant on Yelp, create a dogface emoji on Snapchat, or overpay for a pair of red Prada sneakers on Ebay, and get a strangely similar sneaker ad from Balenciaga the next day.
In every single case (and millions more), mobile SDKs made the transaction, experience, or interaction possible.
Why Are Mobile SDKs Created & How Are They Used?
Mobile SDKs are necessary because mobile app developers can’t build every service that the app or its customers require out of the box. There is no predefined standard or middleware layer in the mobile development tool stack that enables an app to discover, connect to and consume new services or APIs on its own. If a developer did not explicitly build the capability to interact with a 3rd-party service into the app’s source code, then that service simply does not exist (as far as the app is concerned).
Imagine if you were the developer for a ride-sharing app. When you first sat down to build the app, you might sketch out the major components:
- A way to log in through social media accounts;
- A way to pay for the ride;
- A mapping system to show nearby cars;
- A bug tracker to get alerts if the app crashes.
And that’s just the start of the list. We would not have Uber and Lyft today if the development teams had to write their own authentication, payments, and location software. Fortunately, other companies (we call them “SDK providers,” remember?) do that for them!
So, going back to our little brainstorm, you might do some research and discover that:
- Facebook provides a great authentication SDK;
- Stripe has an amazing payments SDK;
- Google has a nice mapping SDK, and
- Bugsnag has a great crash reporting SDK.
SDKs are specific to each platform or OS, and there are variants of the SDK for every OS and/or framework the service intends to reach. The contents of the SDK package can vary, based on factors like: the type of service, the native OS capabilities, the framework used to develop the app, as well as the SDK maturity level.
Generally speaking, SDKs usually include some combination of the following items (not all SDKs include every element below):
- The SDK provider’s APIs.
- API Reference Guide — a document or website containing the information required to work with the SDK providers API, such as the functions, methods, classes, return types, syntax, naming conventions, arguments, ordering requirements — sometimes including hypothetical examples.
- Authentication requirements — including API keys and authentication tokens or cookies as well as the authentication sequence, validation, redirect URLs, authorization requirements, error codes, security requirements (e.g. MFA, encryption, secrets).
This part is absolutely crucial to any SDK implementation because a trust relationship must be established between the mobile app and the service (to ensure that the machines or individuals making the connection requests are legitimate, non-malicious and that the access levels, controls and privileges are established) - Native and/or non-native libraries
- “Plugins” to reach non-native frameworks or non-native libraries (sometimes)
- Sample code (sometimes)
- Debugging information (sometimes)
- UI elements or additional business logic (sometimes)
The Anatomy of a Mobile SDK
There are two sides to every SDK implementation: the mobile application and the service that the mobile application wishes to connect to or consume. But no matter which side you sit on, an SDK is a means to an end.
The SDK provider views the SDK as a relatively low-cost distribution mechanism to get their service embedded inside apps that they don’t own (but that their target customers use). It’s an easy way to reach a large number of subscribers with a relatively low amount of effort. Much of the work is borne by mobile app developers who implement the SDK.
On the flip side of the coin, mobile app developers view SDKs as ways to deliver new capabilities or features in their mobile app without building the functionality from scratch. Again, why build your own proprietary mapping algorithms when you can implement Google’s mapping SDKs to use theirs?
SDKs are a key way that mobile developers build new capabilities into their apps, and before Appdome came along, the ONLY way to implement a mobile SDK was to modify the app’s source code, line by line. It’s a laborious and time-consuming process that involves many repetitive tasks and trial-and-error development. And this process must be repeated throughout the app’s lifecycles for every SDK inside the app.
To implement any new service in an app, mobile developers must formulate their own mental model on how to modify the app’s source code to consume the new service through its APIs. To do this, they must understand every component of the mobile app (the app’s logic, structure, functions, and the complex relationships between all the above). And they must also understand how the SDK provider’s service works. This process entails quite a bit of subjectivity and interpretation. Also keep in mind that many apps are built by teams of developers, who each write a portion of the code, meaning not every developer knows every part of the app inside and out.
Stay tuned for the next installment of this blog series where I will break down the nitty-gritty of what an SDK really is, and outline the steps required to implement an SDK into a mobile application. I’ll also discuss the main challenges and pitfalls (things the SDK provider will likely not tell you), and how you can work around them or avoid them altogether. Or at a minimum, you’ll be more informed about what you’re getting into when you undertake a new SDK project.
Peace!
Alan
