SDK Development Lifecycle

Last Updated 2025-03-08 UTC+8.

There are several stages for Software Development Kit (SDK) Development:

Stage	Description
Design	Design what APIs and sample code should be provided.
Build	Implement the APIs and build the sample code.
Document	Document the APIs and provide comments in the sample code.
Test	Prepare test plan, perform unit / integration / performance / security testing, and setup automated tests.
Publish	Release the SDK to target audience via certain distribution channel(s) and manage licensing.
Maintain	Provide feature / security / dependency / platform updates and bug fixes regularly, ensure API's backward compatibility if necessary.

Design Phrase

APIs

The library APIs should be:

• Easy to understand
• Easy to get started
• Simple to integrate

TIP

Remember the aim is to help developers to solve a problem / simplify their workflow, but not making things very fancy. Simplicity usually means quality.

Sample Code

The Sample Code should be:

• Easy to understand
• Demonstration on most of / all features

It could be a Minimal Viable Product (MVP) to show the minimum working solution; A Feature Playground / Full-Featured Sample App which has all the functionalities of an SDK there; or, Separated Sample Code for each individual feature;

TIP

Remember the aim is to let developers quickly see how this SDK can help them, how easy this SDK can be integrated to their code, and provide examples on the features the SDK provides. Sometimes, having good documentation is already enough, and no need to make things complicated.

Build Phrase

An SDK should be correct, readable, reusable, maintainable, secure, and provide good performance. It should have good versioning mechanism to aid developers understand the SDK changes across different SDK versions.

During the build phrase, we should consider:

Consideration	Explanation
Functionality	Make sure the core features are working correctly.
Modularity	Break down SDK functionalities into modules for reusability, readability, and maintainability.
Use of Protocols	For encapsulation and abstraction purposes, and for easier maintainability and integration, use protocols to define the API interfaces.
Follow Security Best Practices	Ensure good coding practices, perform data encryptions, perform cybersecurity tests, etc. to protect the SDK from malicious attacks.
Optimization	Reduce code complexity, avoid nested loops, use algorithms that are more efficient, use threads for parallel processing, etc., to improve the SDK performance.
Consistent API	If the same SDK are implemented across different platforms, make sure the APIs are using the same / similar names and data types to provide developers a consistent experience in using the SDKs.
Deprecate Old APIs	Mark APIs as deprecated and still continue to support its functionality for a certain period of time before removing it. Provide an alternative API in the documentation. This is to give time to developers and ease them in upgrading their code.
Logging	Include logging functionalities for developers to debug their program easily.
Versioning	Recommended to use semantic versioning. Version each release of the SDK, and provide a clear changelog to developers.
Simplicity	Make sure the sample code is as simple as possible. Avoid using complex frameworks or libraries which introduce technical barriers for using the SDK.

Documentation Phrase

When creating documentation, it's essential to consider how developers will interact with our docs. Here're what developers may look for when they visit our documentation site:

1. Start by highlighting the problems the SDK solves and its key features.
2. Check the compatibility of the SDK with their product and review system requirements and development environment needs.
3. How to install the SDK? Will start following the installation and integration guide.
4. How to get started? Is it easy to integrate? Will start to check the Quick Start Guide or download the sample code.
5. Dive into API references, documentation, and example code for detailed integration.
6. Later when the SDK got a major version updates, they may check out the migration guide.

These considerations help outline the components an SDK documentation should have. Here's how we should design the documentation site:

Stage	Documentation Site Design
SDK Overview	Provide an overview of the SDK's purpose and feature highlights.
System / Dev Environment Requirements	Specify system (e.g. Android / iOS version, device model, etc.) and development environment requirements (e.g., Android Studio, Xcode, Node.js, etc.) clearly.
Installation	Include installation commands, required API levels, language / framework versions, and integration guidance.
Get Started	The Quick Start Guide should be simple and step-by-step, enabling developers to easily build a working codebase themselves. The sample code should be readable, well-commented, and effectively showcase the core features of the SDK.
API References / Code Eamples	Every feature should come with a well-documented explanation and accompanying example code. Additionally, each API should include a detailed description outlining its purpose, properties, methods, data types, and other relevant information.
Migration Guide	A migration guide should be provided for developers to facilitate a smooth upgrade process when major releases occur, ensuring that they can easily transition their existing code to the updated SDK version.

Test Phrase

Testing is of the utmost important part in any software development process to ensure the software matches requirements (validation), and with good quality (verification). This is not specific to SDK Development, so we will discuss about it in other webpages (not available yet, sorry TAT).

Publish Phrase

SDK Licensing

An SDK License is a legal agreement that defines the terms under which an SDK can be utilized, distributed, and modified. There are two primary types of licenses:

• Proprietary License: Under this type of license, SDK developers assert ownership of their work to commercialize it.
• Open Source License: This type of license grants developers the freedom to use, distribute, and modify the SDK.

While these are the two main categories, there exist various other SDK licensing models that offer different terms and conditions for developers to consider.

Maintenance Phrase

There are several triggers for an SDK update:

Trigger	Description
Feature	Introducing new functionalities and enhancements to improve the SDK's capabilities and user experience.
Dependencies	Updating the dependencies used by the SDK to ensure compatibility and leverage the latest features of third-party libraries.
Platform	Adapting the SDK to changes in platforms such as iOS, iPadOS, or Android updates, as well as language and framework updates.
Security	Enhancing the SDK's security by aligning with the latest best practices, such as regularly monitoring security advisories on reputable sites.
Bug Fix	Addressing and resolving any reported bugs or issues to maintain the stability and reliability of the SDK.

We need to have a mechanism for monitoring these triggers, and a SOP for code and documentation updates, testing, and publishing.

References

1. liblab. (2024, January 23). How to build an SDK from scratch: Tutorial & best practices. https://liblab.com/blog/how-to-build-an-sdk
2. 10Duke. (n.d.). Proprietary Software License | Definition. https://www.10duke.com/learn/software-licensing/proprietary-software-license/