Engineering acts as a bridge that transforms a product idea to a successful business.
Developing an SDK from scratch comes with a lot of unknown challenges that could seem overwhelming to an unexperienced team. While at InMobi, I have been a part of the Media SDK development team and particularly at Meson where I built the SDK from scratch. Here, I would like to share my learnings and experiences, and the transformations that I went through as an SDK developer.
If you are a part of an SDK development team, this article will help you gain a few useful tips that will come handy in building and releasing SDKs that will create great products and attract happy customers.
While providing the GitHub link to the repo allow engineers to decode the “How” part, it is equally important to understand the reasoning behind “Why” everything has been built the way that it is now, and that is exactly what we will cover here.
In 2017, Google shifted from Java to Kotlin as the preferred language for Android development. Personally, I realized and appreciated the reasons behind this announcement only after using Kotlin. The two most frequently reported bugs from production in the Android Media SDK team were NullPointerExceptions and OutOfMemoryErrors. Kotlin offered an out-of-the-box solution to these issues.
We picked Kotlin primarily due to these issues, but we enjoyed several other perks as well, such as multithreading with ease, abstracted mundane coding and the highlight of all - multiplatform support. Although we implemented a module with common business logic for iOS, we had to drop it for other business reasons.
However, Kotlin’s multi-platform feature is powerful, and it’s still evolving as a programming language that I plan to cover in my upcoming blogs.
Most of the new products that has to be released must go through the Alpha and Beta releases. At times we need to release faster because of bugs/feature improvements expected to come in large bunches during the beta phase. At Meson, we were lucky to have automated the release job early on, enabling us to release faster and more frequently.
A comparison on the release frequency of stable SDK vs beta SDK for the last 18 months is furnished below:
|
SDK |
Number of Releases |
|---|---|
|
Meson (Beta) |
17 |
|
InMobi - GA |
11 |
|
AdMob/GAM - GA |
10 |
|
FAN - GA |
6 |
Source: http://mvnrepository.com
While building an application, there will be many components for which there will be third party libraries/ SDK available as a readymade solution. Integrate a library based on your specific needs.
Even in the SDK world, there are basic components like network module, Crashlytics, Telemetry, image downloading and caching, serialization, etc. for which libraries are available as solutions.
The problem is that SDKs cannot operate as applications when it comes to integrating third-party libraries because a transitive dependency will be created which can impact in situations like:
Different upgrade cycles of the SDK, app, and third-party libraries.
Crash induced by the third-party libraries.
Larger SDK size when third-party library packs additional functionalities beyond your needs.
Absence of support for the latest platform version from third-party libraries.
End of support or unable to scale because of lack of customizations from third-party libraries.
Again, because there are aforementioned issues with reusing third-party libraries, it is not a straightforward answer that we have to build in-house. Since SDKs are at the mercy of the application, the decision should be based on the analysis of impact for the respective product. What’s important is to be aware of this impact, so that you can plan early instead of redesigning the SDK within few years.
Even if we build a powerhouse SDK which can enable developers to build applications, Unless the consumers know how they can use the SDK, it is still going to be just another SDK. Building a demo app is one of the best ways to showcase the potential of an SDK and various things it can unlock. Integrating the SDK with an application allows us to demonstrate the various use cases the SDK was built for.
There are three kinds of Learning styles - “Auditory,” “Visual” and “Kinesthetic.” Without any research data we can all agree that most of us fall between the “Visual” and “Auditory”, with the visual style being more dominant. Though there are other traditional ways to showcase the SDK usage, such as documentation and Javadoc, a demo app would reach a larger user base.
For example, in Meson we built a similar module called Test Suite which showcases what SDK can offer and allows testing in different ways. We have plans to add much more that will enable a frictionless integration process for the developers.
For more information about Test Suite please visit here
Once the SDK is shipped, we have no clue on the impact it will create for the app. Well, of course unless you have Mr. Sherlock Holmes in your team. Crashlytics/Telemetry exactly plays that role.
Crashlytics/Telemetry is essential for any new products because of the issues and bugs that we may encounter in the beta phase. Without Telemetry/Crashlytics, imagine the permutation and combination of scenarios, we would have to think through while debugging an issue, which can be simplified with the help of telemetry data. Therefore, it is essential we ship telemetry with our first beta release.
Even before starting to write the code, we ensured that there should be gating mechanism to check in code. So, we researched for a static analyzer which covers conventional errors and also offers some optimizations, so we chose Detekt that offered configurability, customizations and community of third-party plugins support. We also made it mandatory in the build jobs to fail if the static analyzer throws warnings.
At Meson, we consciously made this a mandate from the beginning because earlier in the times of Media SDK development, we started following it at a much later stage and by the time we planned to pick it up, it piled up so much that it felt like a mountain in front of us to dig down and fix it.
Although these tasks may seem a bit boring and mundane, we mandated them from the beginning and found them helpful, especially when new engineers join the team, as the process takes care of the transition.
Last but not the least - document every decision, contracts, designs, tests performed and track all the results - even the smallest of details from various meetings, because it is quite common that once the product stabilizes and you wish to expand, the team size grows bigger, and the knowledge transfers starts happening more frequently. Many questions and doubts may arise, and documentation comes in handy so that you do not need to duplicate efforts.
In the world of SDK development, these insights can make a significant difference in the success of your product. By following these best practices and lessons learned, you can navigate the challenges of building an SDK from scratch and contribute to the growth and success of your engineering community.
If there is even a small take-away from my efforts in sharing this with you, it is a win-win situation!
Thank you!
Sign up with your email address to receive news and updates from InMobi Technology
