Paddle’s SDKs (Software Development Kits) are a set of tools, customised for each platform, that make it quicker and easier to use Paddle. They offer features like our checkout, trials, and licensing via native libraries for Windows and macOS.
Paddle’s SDKs are somewhat unusual in a product sense as they are B2B (seller company), B2D (integrating developer), and B2C (end user). What is the seller business wanting to achieve, how’s best for the integrating developer to implement it, and what should the end user experience be?
This presents some interesting challenges for product, design, and engineering - I’ll touch on a few below.
Thanks to our licensing and trial features we’re a target for piracy and reverse engineering, and whilst it can be quite interesting to pick apart a new crack (sometimes they’re creative!) we take sellers need for a secure access control system very seriously.
The other aspect to balance here is that some of the most effective anti-reverse engineering techniques (like obfuscation) can make integration a bit of a nightmare for the integrating developer, so we work with our sellers and integrating developers to find that sweet spot between ease of integration and reduced piracy risk. It isn’t the same for every business, but it does give us a good idea of what sensible defaults are.
Gradual and Unpredictable End User Adoption
Once a release of a SDK build is ready to go public we’ll push the build to the relevant package managers (and GitHub repos) with release notes that are a hybrid between a developer change log and a summary of functional changes for a product or business owner.
Sellers will typically include the updated SDK into their next planned product update, as they might need to make some functional tweaks and put it through QA. Naturally, the timings of these can vary significantly from seller to seller, and depending on if their next version is incremental or a major new release.
The good aspect of this is that our backend platform load increases slowly over time, with the occasional spike, as larger sellers ship their updates. The trickier part is that we have to be very careful about maintaining backwards compatibility, especially with SDK API endpoints.
macOS Dynamic Libraries
Feel like using that fancy new 3rd party framework on macOS? Thanks to how dynamic libraries work we can’t. 🙂
We ship the Mac SDKs as dynamic libraries because we have UI files and other assets, something static libraries don’t support. This means any 3rd party libraries we might include aren’t exclusive to our framework, so they can clash with the integrating sellers/developers.
This is a positive in terms of avoiding unnecessary bloat in our frameworks, but it does mean you can rarely use something “off the shelf”.
The challenges are clearly worth facing though, as we have strong macOS market share and are looking to refine and expand the experience.
In the same vein we’re doubling down on Windows and are actively developing a new and improved C# SDK. We’re currently doing research and talking to sellers to understand how we can add the most value on the platform but already have sellers using it in the wild.