What's an SDK?
How developers outsource their code (sort of).
The TL;DR
SDK stands for Software Development Kit, and it’s just that: software that helps you build other software.
Developers don’t write all their code from scratch: they rely on bits of reusable code from others
That outsourced code and can be free and open source, or paid and closed source
Libraries are smaller, more specific groups of this code, while SDKs are larger, more comprehensive ones
Common SDKs: developer tools like Stripe or platforms like iOS
SDKs are a hard thing to understand because the term can mean so many things, up to and including low level details of programming hardware. In this post, I’ll give you the definition that I think most professional developers have in mind when they talk about SDKs.
Software on top of software on top of s-
If any readers have dabbled in learning how to code, you might start with a completely empty file, and write a basic program that does something cheeky like print “hello world” 10 times:
for i in range (10):
print “hello world”This (surprise) is not at all what professional software development is like. And it’s not because professional developers aren’t tasked with writing dinky programs that output “hello world” – it’s because professional developers almost never start with a blank slate. Modern software development is built on layers and layers of other people’s code. Allow me to explain.
Code is a very basic tool: it allows you to express logic and the movement of data. For the things that developers need to do today, like building a web server, a reactive frontend, or accepting payments, writing the code to do that from scratch would be like building an entire skyscraper yourself. It would take basically an infinite amount of time. And companies, especially startups, do not have infinite time.
Instead, developers rely on code from other developers to do many of the tasks that they don’t want to do. In turn, that code from other developers relies on even more code from even other developers to do what they didn’t want to do. And so on and so forth. This incredibly complex (and fragile) network of what are called dependencies are the subject of the popular xkcd comic:
Some of these dependencies are free, open source software that is indeed thanklessly maintained by someone in a flyover state. But some of them are closed source, paid, highly polished and professional code from a company like Stripe. And yet another category is a wrapper of code on top of a service that you can also use in other ways, like MongoDB.
Outsourcing your code: libraries and SDKs
The best possible way I can explain an SDK is this. When it comes to outsourcing your code and using someone else’s to get a job done, there’s a wide spectrum of how much you give up to other tools.
A library: a small, focused set of reusable code with a specific purpose.
An SDK: a comprehensive set of reusable code with a broader purpose.
Let’s run through a few examples. We’ll start on the library side – small little things – and gradually move to the SDK – very big, comprehensive things.
Working with dates
Applications need to work with dates and times all of the…time. I’m writing this post inside of a Google Doc, which has an edit history feature:
But dates are hard. There are a lot of different time zones. Different clocks on different hardware show different times. And every country likes their dates formatted in different ways. Writing code to handle all of this from scratch would be annoying.
Instead, you can use `date-fns`. It’s a small library with one specific goal: making it easier to work with dates and times in JavaScript. Here’s how you’d format a date to match my personal preference of MM/DD/YYYY:
const date_the_way_I_want = format(new Date(2024, 11, 9), 'MM/dd/yyyy')And `date-fns` like most libraries of its kind is totally free and open source.
Making API requests
Developers need to make requests to APIs in their code, whether those are internal APIs their teammates have built, or external ones from providers like Google Maps. Making requests is hard: you have to attach the right data, authenticate, handle the response data, and figure out what to do if your request fails.
Slightly larger in scope than dates, but still in library territory, is something like the `requests` Python library, which helps developers do all of these things. You can make a request to an API with a simple line:
r = requests.put('https://technically.dev', data={“new_post”: “what’s an SDK?”})Libraries like this exist for other programming languages too, like Axios for JavaScript.
Accepting payments
Working with dates and making API requests are pretty specific tasks. But what if you needed to do something with a larger scope, like building the ability to accept payments into your app? That’s more than a few functions: you need to be able to store and charge a credit card number, allow users to select monthly or yearly plans, generate and send invoices, work with payment data ad hoc (refund a customer, etc.)...there’s a lot. This is no longer library territory, this is the domain of an SDK.
And this is (part of) what Stripe does. They provide many interfaces for you to outsource this kind of code and just use a few lines to get these incredibly complicated tasks done. Canceling a subscription is as easy as one line:
stripe.Subscription.cancel('{{SUBSCRIPTION_ID}}')Working with iOS
On the “most comprehensive” or “most complicated” side of SDKs, you have the iOS SDK from Apple. If you want to develop a mobile app for iOS, you need to use Apple’s iOS SDK – and most probably their UI language called Swift. It’s a lot of reusable code and APIs for building apps that work on iPhones and iPads, plus its own development environment (XCode). The code looks nothing like a normal script you’d write in Python, and requires you to get familiar with an entire new taxonomy of app layers, views, and other Apple specific things:
So when it comes to outsourcing your code, the realm of possibilities ranges from a tiny little date manipulation library to a comprehensive suite of tools for building iOS apps. The line between a library and an SDK isn’t something defined by peer reviewed science. It’s more of a spectrum:
In my not so humble opinion, thinking of the world of outsourced code on this spectrum is the best way to understand libraries and SDKs and what they accomplish for developers. And the more towards the SDK spectrum you go, the more supporting materials you need to be successful with the SDK. That’s why developers can sometimes refer to an SDK’s documentation, tutorials, or sample apps as part of the SDK itself.
SDKs vs. APIs: it’s how you use it
A common question I get is the difference between an API and an SDK. I think user Jason S from StackOverflow does a great job of setting the stage:
To translate this into Technically language: the APIs are what actually get the task done. Stripe’s APIs are the things that actually do the work of charging credit cards, creating and canceling subscriptions, sending invoices, and all of the stuff that you pay Stripe to not have to do yourself. You could use the APIs yourself if you really wanted to.
But the SDKs are how you use the APIs. They’re all of the nice things Stripe has built that makes it easier to consume their APIs, like:
Wrappers for your favorite languages like JavaScript and Python so you don’t need to call the APIs directly
The Stripe UI and their test data feature, so you don’t have to keep charging your own credit card to see if your app is working
Documentation and sample apps to help you build faster
And this is exactly how Stripe themselves describe the word SDK:
The Stripe integration is the actual sauce, the software that does the hard work for you. The SDK is how you practically use that thing in your Ruby app.
Unfortunately for you, developers will sometimes use these terms interchangeably. So next time the term SDK comes up at work, don’t be afraid to ask: what do you mean by that? Their APIs, or the SDKs themselves? And you might get a little street cred along the way.