SDK (software development kit) – a set of ready-made tools in one package, which contains documentation, API, code, libraries and other.
Working with the SDK is much harder than with the application because you can’t do frequent releases due to possible negative user feedback, no automatic version updates, problematic running A/B-tests and high bug costs.
With all these disadvantages, a competently created SDK:
- Will help to increase the target audience. For example, if previously your program was used only through the website, after developing the SDK for applications, your potential customers will
- Also be smartphone owners.
- Speed up integration.
- Improve the quality of the code and allow it to be reused.
- Bring the behavior of all systems to the same standard.
- To create a reliable SDK for applications, the head of mobile development, we have compiled a checklist in the article.
It will be useful for product owners, team leaders, technical specialists, and anyone else who wants to develop their own SDK.
The idea to create a checklist came after a phone call with a client. His SDK users complained about the lack of visibility in connecting the SDK to their projects and the inconvenience of the API. Because we already had experience with creating payment SDKs, advertising SDKs, and chat rooms, we were tasked with finding a way to make the SDK connection simple and obvious, and the API convenient.
Rinat Shamshutdinov, the head of mobile development at SimbirSoft, prepared a checklist to help with the main points when creating a reliable SDK for applications. This material can be useful for product owners, technical specialists, and those who think about creating SDK for their own service.
The advantages of creating your own SDK (software development kit) are indisputable: with it you can significantly expand your target audience, as well as the target audience of your customers. Let us suppose that your acquiring service has so far been used only on websites. After you create an SDK for mobile apps, you’ll have new clients – an audience of mobile app users.
Developing your SDK is a more difficult task than developing an app.
There are several reasons for this:
Users (other developers) tend to be negative about SDK changes that might affect their apps. You can’t roll out a new version often; HotFixes are unacceptable. How to deal with this, below.
The distribution of a new version of the SDK to clients is not automatic. You may have a situation where customers will sit with the SDK version released a couple of years ago because they are happy with it and they don’t want to spend the resources to upgrade to the new version.
It’s hard to do classic A/B testing. Due to the lack of automatic SDK updates from your clients, you won’t be able to quickly test hypotheses through A/B testing.
Since the SDK affects customers’ apps and their users, the cost of a mistake is high: millions of people could be affected, and the business could suffer serious losses.
If you think carefully about the following points, you can avoid most of the problems in the future. So, when creating the SDK, you need to:
1. Choose the technology
You need to find a compromise between the labor cost of SDK development and compatibility support.
A pure Java SDK with Thread can guarantee 100% compatibility for years to come. If you are using the latest technology, you will need to keep up to date with updates to that technology and release a new version of the SDK as the technology changes. We recommend limiting yourself to using programming language tools and the Android SDK/iOS SDK. When using additional dependencies (e.g. RxJava/RxSwift), be prepared to constantly update the SDK as new versions become available.
For example, Apple advises against using libraries, as incompatibilities may arise between library versions within the SDK and within client applications. For the iOS platform, you can’t build XCFrameworks into another XCFrameworks. In the case of Objective-C, there can be collisions since all classes live in the same namespace. If you write an SDK in Swift, remember to use @objc annotations to generate the header file. This is necessary so Objective-C applications can use your SDK.
2. Provide API flexibility for clients
There is a choice between easy customization and flexibility.
For payment SDKs, you can only provide clients with a payment screen launching with transferring the amount, payee information, and payment metadata. The bank card number entry and payment confirmation screen can be done within the SDK. For customers, this API option gives the maximum ease of configuration, and for business – the ability to painlessly change the SDK. The flexibility of configuration suffers in this case.
The other option is to give direct access to server methods, including payment confirmation, cancellation, etc. In this case, customers will not always be able to properly configure your service, and thus there is a high risk of support service overload and an increase in the number of negative feedback if any errors occur, even if the errors will be in the clients’ code, not yours.
When developing an SDK, it’s important to provide clients with a stripped-down API first. Later, when the work is fine-tuned, you can add a customization option for users.
3. Perform testing on real data
To test the SDK, you need your own custom application where the SDK can integrate. You should always test on real data before putting it out to the public. For example, make payments through real cards from different banks. You also need to cover the SDK with unit, integration, and scripting autotests to reduce the chance of missing a bug when you change the SDK.
4. provide a customer-friendly API – your customers’ developer experience
Ask teams from other projects in your company, developers you know to try integrating the SDK and leave feedback on usability. You can make a sampling among your customers and ask them to test the new version of the API, for example by offering them a discount in return.
Post an alpha version of your SDK on GitHub and ask the community for feedback on what could or should be changed. This way, you’ll increase customer ownership of you and your product.
5. Prepare documentation
As a user of other people’s SDKs, I can confidently say that the documentation should be written clearly and in detail, so you can clearly by the instructions, without thinking, connect the SDK. Ideally, there should be code examples in the documentation. As a good documentation you should look at Google.
When changing the SDK, I recommend writing examples of migration from the old SDK to the new one. Here, too, you can refer to Google’s experience.
6. Make a sample project
For developers, besides documentation, you need a sample project. The code tells you how to use the SDK better than any documentation. Creating a good sample project requires resources – developers’ time. Be sure to document the lines where you configure and call the SDK.
The sample project will also help you understand if the SDK is easy to embed and use.
7. Take care of the size of the SDK
Since any dependency will transitively pull into the SDK client application, increasing its final size, you don’t want to add heavyweight libraries to the dependencies, such as C++.
Some clients are sensitive to resizing. It may be easier and more convenient to write your own implementation of some tool.
8. Think about where the SDK will work
For Android, you need to think about where the SDK will run: in the application process or in a separate process.
By default, the SDK runs in the same process as the client application. This is where the main danger lies: if the SDK crashes, the client application will also “crash”.
There are examples where the SDK runs in a separate process. But here, remember that this would create a new instance of the Application class, and this could disrupt the SDK or the application.
9. Think about the ways of distributing the SDK
Handing it to the client in person, via Maven Central, GitHub, etc.
Each way has its pros and cons. For example, when distributing your library through Maven without Internal Repositories, you should be prepared for anyone to use it. Promoting through GitHub is similar to Maven. If you publish for free, everyone will be able to download it. Paid distribution can be arranged through a private repository. Private distribution will be convenient only for a small number of clients.
For iOS it is desirable to add support for standard library dependency managers – Cocoapods, Carthage, SPM. Also there is always an option to distribute through GitHub as a subproject.
10. Provide an opportunity to fill the SDK
When creating the SDK it is best to consider whether you will change the content of SDK depending on the client who will use it.
If you plan to, you need to fine-tune the product flavors/target, so that the client gets exactly the right assembly.
11. Licensing the SDK
If you want to use help from the community to improve the SDK, you should license it freely, choosing, for example, MIT/Apache 2.0. Also carefully consider the licenses (quick note here) of libraries, fonts and images which you use in your SDK. Even a paid font in the design of the mobile SDK may violate the license.
12. Secure the SDK
When designing an SDK, it’s important to assume that potential customers will be able to read your code, even if it’s obfuscated. Therefore, in terms of security, first of all, you need to provide protection on the server side – from the same DOS attacks. As part of the SDK, you need to make sure that only public API methods and classes are available to the user.
For security reasons, Apple, for example, recommends embedding dependencies in the SDK. Before upgrading a version, security officers at large companies double-check these dependencies to make sure that the author of the third-party library has not added any compromising code.
Bottom line
SDK development has many complexities and requires a lot of experience from the team, it is an area that requires constant learning. In turn, the SDK helps to expand your target audience with mobile users and increase profits in the long run.
