The value of a network is proportional to the square of the number of connected users.
Metcalfe’s law of network effects is what drives the exponetial growth of technologies like the Internet. Any business model that benefits from having more interconnected parties can exploit network effects to drive growth.
The key enabler is making on-boarding to the network or system easy and seamless. It is no coincidence that in the dawning of the Internet age this was the approach taken by the likes of AOL and others. There are no doubt vast quantities of AOL CDs now buried in landfills across America, but it was this ubiquitous, free, and easy to use software that introduced millions of people to the Internet.
What is the modern AOL CD equivalent?
For end users it is probably a website or app’s onboarding experience. But what about services or platforms that require 3rd party developers to integrate via an API? Well that is where SDKs (Software Development Kits) come in.
Good SDKs are awesome
A good SDK enables an app developer to quickly and effectively connect their app to a platform and thus extend its reach, making it more valuable.
But what makes for a good SDK?
Over the years we’ve integrated many (good and bad) vendor SDKs into apps we’ve built for customers. We’ve also helped a number of well known companies develop and maintain the SDKs for their products & services.
The quality of an SDK is often a direct reflection of how seriously a company takes 3rd party integration. What do developers like ourselves look for when evaluating an SDK and how can a company ensure that it is publishing a high quality SDK that developers will be eager to integrate into their app?
Good SDKs should
Be Useful
The time cost of integrating, supporting and maintaining a vendor SDK needs to be significantly offset by its utility. Good SDK vendors seek to understand the needs of developers who are integrating with their service. An SDK should provide easy to adopt solutions to common needs that save developers time.
A good example of this is the Stripe iOS SDK which provides both low level code for interfacing with Stripe’s REST APIs as well as fully featured UI components for delivering complete payment flows. This helps satisfy the needs of developers who want complete control over their app’s user experience as well as those who need to quickly throw in a default payment experience.
Be easy to integrate
SDKs should be distributed using the tools and channels app developers are already using. This likely means being hosted on GitHub and engaging with the developer community through the tools provided there.
Nearly every development platform has a standardised dependency management system. Be it Swift Package Manager (and historically CocoaPods and/or Carthage) for iOS, Gradle for Android, or NPM for JavaScript. A good SDK will support the most common dependency management systems for its target platforms as well as provide manual integration mechanisms for developers who can not, or choose not to use these systems.
Bad SDKs require developers to login to developer portals and manually download SDK binaries or sources, or require developers to use special build tools, scripts or manual steps in order to integrate.
Be well documented
Having good documentation for an SDK is essential. Starting with a README that guides developers through understanding what the SDK does and how it should be used. Further documentation should provide examples & guides on how to integrate the SDK and how it should be used.
The mechanisms for reporting bugs and requesting support should be clearly documented and easy to access. Ideally using the issue tracker and discussion forums built into GitHub for this purpose.
An SDK’s APIs should be comprehensively and accurately documented using the documentation systems built into Swift and Kotlin and each release of the SDK should be accompanied by a comprehensive change log.
When an SDK is open source it should have a contribution guide and code of conduct and the code in the repository should be clearly licensed.
Be transparent about how they work
The best SDKs are open source and licensed in a permissive fashion using the Apache, MIT or BSD licenses.
In 2020 many developers who used the Facebook SDK experienced crashes that stopped users from launching their apps. These crashes were quickly resolved because that SDK is open source and open to contribution.
Enabling developers to inspect and modify the code means they they can know exactly what they are including in their apps. They can debug and fix it when necessary. A permissive license gives them confidence in the legal requirements relating to the use, modification and inclusion of the SDK’s code.
SDKs should not use the LGPL, GPL, or “custom” open source licenses as they introduce legal risks and ambiguity when integrating with the SDK. A proprietary license for an SDK should be avoided unless it is absolutely necessary to protect intellectual property. Ideally the intellectual property is behind the walls of a service’s APIs, not part of its SDK.
Again, it is not ideal, but if an SDK is only available as a binary then the documentation should be very transparent about what it is doing “under the hood”. It can be particularly problematic if an SDK overrides or intercepts platform APIs because doing so can introduce unexpected behaviour into an app and be very difficult for developers to debug. This buggy or strange behaviour may give the SDK a bad reputation.
Binary only SDKs also need to be very clear about what internal dependencies they have on other libraries or code. Ideally they should have none, as it is possible for these internal dependencies to conflict with dependencies used by the integrating app.
A good SDK leaves all initialisation and loading in the hands of the application developer and does not not load itself automatically or inject itself into the application logic without the developer’s knowledge. It should also provide a mechanism for the developer to shut the SDK down at runtime so that it can be easily turned off if it starts causing problems.
Good SDKs are also completely transparent about what information they collect at runtime and what is shared with other parties. The integrating developer should have complete control over this collection and sharing. It should be configurable and optional where possible. This is vitally important given that applications must be compliant with regulations such as the GDPR and other national and international privacy and data regulations.
In addition to government regulations, platform holders such as Apple now require developers to disclose the ways in which their applications collect and share user data. If an SDK vendor does not provide this information, or give developers tools to control this behaviour, then they will be more reluctant to use that service.
Be regularly maintained
SDKs need to be regularly maintained to be kept relevant. Platforms are constantly changing and improving, so it’s easy for an SDK to become out of date if it’s not regularly updated and tested against newer versions of the toolchains and operating systems.
Be idiomatic to the platform
The languages, tools and techniques used to build apps are constantly changing. What was bleeding edge a few years ago is now “the old way of doing things”. SDKs need to keep pace with the platforms they target to ensure that they remain relevant and work in ways that are idiomatic to the platform.
Language support, naming conventions, method signatures, calling conventions and programming paradigms all need to be considered. Using old conventions or trying to impose conventions from another platform will only serve to frustrate developers and make them less likely to adopt the SDK.
Conclusion
As you can see, building and maintaining a high quality mobile SDK that elevates a product or service is not easy nor trivial. But the effect on a product or service’s growth will be commensurate to the investment made in delivering a high quality SDK to customers and the developer community.
