During the beginning of 2023 I was hosting a tech talk about SDKs, publishing an open source product and some lessons I learned. In this post I am going to share some key points of the presentation.
First, I would like to thank my team in Twilio, The Apps and SDKs team. Without their help and feedback I wouldn't collect all these lessons.
What is a Mobile SDK
It's a precompiled, static code that can be added to an app. It provides a set of functionalities without have to write any code by the developers.
Why companies build SDKs
For some business like Twilio, the products portfolio and services are meant to be consumed through implementations. By providing an SDK the complexity of implementations is reduced, and customers can consume and billing in less time.
Also, there is a growing demand of companies that search for built-in solutions, specially startups looking for launching to the market quickly and focus in its own business.
SDK Types
There is a SDKs classification popular on Internet that states the following types:
- Mobile-exclusive: SDKs that brings services for apps only. Some examples: Crashlytics, Instabug, Appsflyer, Ad Mob.
- API-based: Companies already have an API, but the experience is much better using the SDK. On the other hand, some use cases require several API calls, like an authentication token renewal, and could be simplified by chaining the request in a single SDK invocation. Some Examples: Facebook, Spotify, Twitter, Stripe.
- Hardware components: SDKS made for using an specific hardware. Some examples: Arcgis, DJI, AR Core.
At Twilio, we create API-based SDKs most of the time, so I can tell more about them coming up.
The developer experience matters
As user experience matters, the developer experience too. If a company's main product is a software as a service, the developers will be the first people that can have a review about the quality of the service. That's why SDKs play an important role by decreasing the effort of the integration and keeping developers happy.
The SDK is a foreigner in the app
The SDK is a foreigner that transits with special permission in the app. To maintain this privilege you must show good behavior. this is a list of bullet points to consider in an Android app:
Thread Management
To avoid the Application not responding error, it is required to switch to a background thread any heavy execution.
In the team we choose to do an “early return” of a custom exception when the SDK detects that it is running on the main thread. This means that before starting a long time operation, if the current thread execution is the main one the code will throw an exception and stop.
Size
Size is a property that greatly influences developers to choose between my SDK or the competition's one. When possible, use own implementations instead of external dependencies, so that unnecessary additional features are not imported.
The size of the SDK is not just the size of the .arr file. To get a real estimate, compare the size of an example app (the .apk file) before and after integration with the SDK. This is due to factors that have to be taken into account, such as adapters and providers in the dependency graph.
Transparency
An advantage of open sourcing is that the code is not a black box for the developer, which is quite appreciated by companies in which security matters and can analyze the code of the entire SDK. Anytime a developer wants to check inside the SDK, they can just go to the repo and that's it.
Conventions
Based on the SDK programming language used (I hope it is Kotlin), Adhere to the platform conventions, the official code guide and design patterns that make it consistent with what the Android developers are familiar with — so the SDK feels like a natural extension of the platform. Avoid reinventing the wheel by introducing new conventions that may be alien to the developer.
Platform parity
At the same time that I was developing the SDK for Android, there was also a developer working on the iOS version. We try as much as possible to use the same names for repositories, business classes, functions, packages and exceptions. This allows us to speak the same language when technical or business discussions were taking place. Communication with QA turns out to be easier since it is only necessary to learn terminology for both platforms when testing.
On the developer's side, parity between platforms allows cooperative work between developers for different operating systems, knowledge can be exchanged and doubts cleared during installation, reaching the level of the learning curve sooner.
The implementation was not expected to be 100% accurate. Not everything can be parity, it is good to use patterns specific to each language and technology to make the code more familiar to the developer on an specific platform.
Make the installation as instant as possible
An SDK is an excellent opportunity to present products. Making the installation of the SDK on apps as fast as possible contribute to a high adoption rate.
If the business requires installation through a purchase, a good idea is to have a free trial that can be explored.
Provide a quickstart in the readme of the repository. The quickstart is not just a section, it is a "business card" that can hook and prevent the developers from abandoning the process.
Create an open source project is also create community
Open sourcing is not only about keeping a project open to the public, it is also about having a receptive attitude and encouraging others to contribute. Code repository managers such as Github provide tools and guides to build a community around the SDK that contributes effectively and safely. You can check the resources here.
Final thoughts
Mobile development extends far beyond traditional applications and libraries. Among these, SDKs stand out as promising opportunities for businesses, yet they remain largely untapped. Developers can significantly broaden their skill set by engaging with these types of projects, gaining valuable experience.
Top comments (0)