Skip to main content

Back to the liblab blog

SDK examples, use cases & key characteristics of a good SDK

| 13 min

SDKs are everywhere, and help developers build software faster and easier. In this post I take a look at some examples of a few SDKs, and talk through the use cases and characteristics of a good SDK.

What is a Software Development Kit (SDK)?​

We cover this a lot in one of our other blog posts - how to build an SDK from scratch, but essentially Software Development Kits, or SDKs, are code libraries containing an abstraction layer that makes it easier to interact with a piece of software or hardware using your preferred programming language, speeding up your application development process.

A block diagram of code calling an SDK that calls an API. The code is represented by a plushie llama using a laptop, the arrows between blocks are plushie brown arrows with a neutral facial expression. The SDK is a plushie block fox with SDK written on it, and the API is a plushie block with API written on it, a smiley face, and a swirl of cream on top.

The developers code interacts with the SDK, and that in turn interacts with an API, hardware, or other software.

Some examples of types of SDKs include:

  • API SDKs - these are used to interact with an API, such as the Twitter API, or the Stripe API.
  • Hardware SDKs - these are used to interact with hardware, ranging from consumer devices like printers, to IoT devices, smart consumer devices, and more.
  • Mobile SDKs - these are used to interact with mobile devices, such as the iOS or Android SDKs. If you want to use your phones camera, or handle notifications, you need to use the mobile SDKs.
  • UI SDKs - these are used to implement user interface components, in web sites, on mobile apps, or in desktop applications.

List of SDK Examples​

There are many types of SDKs, and thousands of SDKs available. Here are a few examples of the types of SDKs mentioned above:

API SDK​

An API SDK is a an SDK that makes it easier to use Application Programming Interfaces, or APIs. Many SaaS and cloud companies have APIs to use their tools and products, and calling these APIs directly is not usually the best approach. You can easily end up writing a lot of boilerplate code to handle things like authentication, retries, and more, in your programming language of choice.

A cute llama using a laptop

An API SDK on the other hand will provide you with an SDK in the languages you are using, and it will handle all of the boilerplate code for you, usually implementing the best practices for that API. For example, an SDK can implement authentication in a way that makes sense for the API, or handle retries and backoff in the most appropriate way.

These SDKs are also structured to make sense to the developer using them. This might be by splitting up the API into multiple SDKs, or wrapping multiple APIs in one SDK. They will also provide code examples, documentation, and more in the available SDK languages.

You can read more on the differences between an SDK and an API in our blog post SDK vs API: what's the difference?

Examples of API SDKs include:

  • Stripe SDK - this SDK makes it easier to interact with the Stripe API to handle payments. The Stripe SDKs wrap their APIs for a huge range of programming languages and technologies.
  • Twilio SDK - this SDK makes it easier to interact with the Twilio API to handle communications, such as SMS, voice, and video.
  • AWS SDK - this SDK makes it easier to interact with the AWS API to handle cloud services, such as storage, databases, and more.

Hardware SDK​

Hardware SDKs provide an abstraction layer for communicating with hardware tools rather than software tools. This could be a device connected to a computer, such as a bar code scanner, to remote devices such as Internet of Things (IoT) devices, to hardware connected to a mobile device, such as credit card readers.

A cute llama using a credit card

Communication with hardware is typically low level code, and can be very complex. A hardware SDK will provide a higher level of abstraction, making it easier to interact with the hardware.

Examples of hardware SDKs include:

  • Square reader SDK - the Square Reader is a credit card and contactless payment device that connects to mobile phones. This SDK allows you to integrate payments into your mobile apps using the reader hardware. This reader can be connected over an audio jack, so the SDK handles converting audio signals to the data the reader needs, and back to the data your application needs.
  • Tuya IoT App SDK - this SDK allows mobile app developers to build apps that interact with Tuya's range of smart home and IoT devices. It can handle pairing of devices, device configuration, and device control, over multiple protocols from Zigbee to Matter. The SDK abstracts the protocols and device types, making it easier to build apps without caring about the underlying technology.
  • Zebra Scanner SDK - this SDK allows you to build applications that interact with Zebra's range of barcode scanners. It provides a higher level of abstraction than the low level barcode scanner APIs, making it easier to build applications that interact with the scanners.

Mobile SDK​

Mobile SDKs are used to interact with mobile devices, such as iOS and Android. These SDKs provide a higher level of abstraction than the low level APIs provided by the mobile operating systems, making it easier to build applications that interact with the devices.

A cute llama using a mobile phone

Some mobile SDKs are provided by the device manufacturer, and usually these are limited in the SDK languages you can use. The are third party SDKs that sit on top of these, and provide support for other languages, or a consistent development experience across multiple devices.

Examples of mobile SDKs include:

  • iOS SDK - this SDK provides a range of APIs for building applications on iOS devices. It includes APIs for interacting with the device hardware, such as the camera, and for interacting with the operating system, such as handling notifications. This SDK primarily supports Swift, but you can create apps using C++ and Objective C.
  • Android SDK - similar to the iOS SDK, this SDK provides a range of APIs for building mobile applications on Android devices. This SDK primarily supports Java and Kotlin, but you can create Android apps in C++.
  • Flutter SDK - this SDK provides a range of APIs for building mobile applications on both iOS and Android devices. It provides a consistent development experience across both platforms, and supports the Dart programming language.
  • .NET MAUI - this SDK provides a range of APIs for building mobile applications on both iOS and Android devices. It provides a consistent development experience across both platforms, and supports C# and F#.

UI SDK​

UI SDKs provide user interface components for you to use in your web, mobile or desktop app. These abstract out a range of user experiences in different programming languages, and provide a consistent look and feel across different platforms.

A cute llama designing a web site

Examples of UI SDKs include:

  • DevExpress - this SDK provides a range of user interface components for web, mobile and desktop applications.
  • MUI - this SDK provides a range of user interface components for web applications, and is built on top of React.
  • Material Design - this SDK provides a range of user interface components for web applications, as well as mobile apps built using Android or Flutter. This is built on top of Google's Material Design system.

Use Cases for SDK Implementation​

With all the different types of SDKs, the general theme is the same - they provide a way to build functionality into your application without having to write all the code yourself. Here are some use cases for implementing an SDK:

Payments​

We all like being paid right? But handling payments can be complex, with a lot of edge cases to handle. A payments SDK such as Stripe can handle all of this for you, from handling the user interface for entering payment details, to handling the communication with the payment provider, and handling the response from that payment provider. If you are building a platform where you need to charge someone, you can add payments in only a few lines of code calling the relevant SDK.

Analytics and metrics​

As developers we want to know who is using our apps, what features they are using, how they discover those features, and in-depth details when things go wrong. It's reasonably quick these days to add analytics and metrics to an application using an SDK such as Sentry. Again, a few lines of code and you have analytics, metrics, and error tracking.

Social Media​

Social media has changed how we interact with our customers, potential customers, friends and colleagues. There is a lot a developer can do with social media, from getting alerts when their company is mentioned, to scheduling posts. A social media SDK can allow you to integrate this functionality into your own apps.

Custom relationship management (CRM)​

Custom relationship management, or CRM, software often needs to integrate with other systems, such as the systems you are building as a developer. For example, if you wanted to add a contact form to your website, and want to feed that customer data to your CRM. This can be done using the CRM SDK, with different SDK capabilities from a full UI component that does everything, to a more lighter weight SDK where you send the form data to an SDK call.

Characteristics of a Good SDK​

Whilst in principal an SDK should make your development experience better, this is not always the case. There are some great SDKs out there, as well as some utterly terrible ones.

Here are some characteristics of a good SDK:

  1. Easy to install - whilst easy is a subjective term, your SDK needs to be easy for your users to install. Sometimes this is as simple as ensuring it is hosted on a package manager, such as npm, pip, nuget, or maven.

  2. Documentation - without good documentation an SDK can vary from being hard to use to being useless. Good documentation should include reference documentation in all supported languages, guides to implementing common functionality, and tutorials to get you started quickly.

  3. Code samples - developers love to copy and paste, and having great code samples really helps developers build apps quickly by taking anything from inspiration, to huge swathes of code, from your examples. These can be inside your documentation, or in a separate examples repository on GitHub. Good code samples can even help guide AI coding assistants inside your integrated development environment or IDE.

  4. Sample apps - an extension to code samples, sample apps can help your users understand the bigger use cases for your SDK, and see how it can be implemented across a larger application, instead of just in one place. As software developers create their apps, these samples can speed up their time to deliver as they can provide a complete reference implementation. For example, an app with example code showing how user authentication can be implemented in one location in your app, and then how that authenticated user can be used across the app.

  5. Idiomatic to the language - a good SDK supports a range of programming languages, and for each language the implementation should be idiomatic to that language. From documentation in the right format to allow for easy integration with IDEs, to using the right language features, a good SDK should feel like it was written by a developer who knows the language well making software development using it feel natural. It should also not re-invent the wheel, using the standard libraries and frameworks for that language where possible.

  6. Few dependencies - it's very easy for an SDK to have a huge amount of dependencies, and this can lead to problems managing these when you want to add dependencies to your own project. A good SDK should have as few dependencies as possible.

  7. Simple to use - simple is another subjective term, but a good SDK should feel to the developer like it is easy to use, and expresses concepts and patterns in a user centric way focusing on the use cases that a developer might have. Your SDK should be written with an understanding of the types of problems your users want to solve, and provide convenient ways to do this, not just be a wrapper around your internal database structure or your hardware. For example with a bar code scanner SDK, developers using it probably just want to get an event fired when a barcode is scanned with the bar code number, not have to worry about writing control loops to monitor for what the scanner is detecting all the time, polling to see if a bar code is found, then getting the code.

  8. Up to date - a good SDK should be up to date with the latest version of the API or hardware it is wrapping. This can be a challenge, but it is important to keep your SDK up to date, as your users will want to use the latest features of your API or hardware. To help with this, make your SDK as maintainable as possible (for some tips with TypeScript SDKs check out our Quick tips for making your SDK more maintainable in TypeScript: routes edition article). For API SDKs consider auto-generating them using liblab to avoid having to spend time maintaining them when your API is updated, adding auto-generation to your development process.

Conclusion​

A good SDK can greatly improve the developer experience for your users. For hardware they get a nice abstraction that is easier to program against rather than sending raw, low level hardware commands, for an API they get models and service classes that make it easier to interact with that API, handling things like authentication, retries and more for you. For more on should you build an SDK, check out our article on 'why do I need to build an SDK'.

SDKs are a great thing to provide to your customers, but can be a lot of work to build. This is where liblab comes in, allowing you to quickly generate SDKs for your APIs.

If you have an API and want to improve your users developer experience with an SDK, sign up for liblab now at liblab.com/join.

SDK