Like Uncle Ben said, with great power comes great responsibility… After developing Android apps for over now, I recently joined to lead the Android SDK development for the platform. 3 years Mitter The transition from being an app developer to an SDK developer as smooth as I thought it would be. It took some change in mindset to get to where I am today. Nevertheless, the change wasn’t too hard. wasn’t A simple of recognizing that a change in approach is needed and the willingness to act on that thought, did the trick. concoction Here’s what I learned in the last : 2 months 1. No more assumptions “Differences challenge assumptions.” — Anne Wilson Schaef When you’re an app developer you get the freedom to make all kinds of assumptions on how your app should behave. You are the captain of your ship. This attitude doesn’t quite fit in when you’re writing an SDK. Suddenly, you’re stripped of your license to assume. Whoops! When you’re developing an SDK you’re merely acting as a middleman to help a creator see the end of the line without getting in the way. You can’t just shove down rules or conventions down a developer’s throat if you want to build a truly helpful SDK. 2. With simplicity should come flexibility “Simplicity is the ultimate sophistication.” — Leonardo da Vinci Another mark of a remarkable SDK is simplicity. No matter how complex or a platform looks from the outside, an SDK should make the process of interacting with the platform, a walk in the park. daunting You can’t be lazy on your side hoping that developers would work around your crappy design. If your SDK takes a lot of time to get a hang of, it’s very likely that developers will ditch it for good. You should work on by providing simple set-up, and lots of handy functions to get the job done, get the ball rolling. reducing friction This doesn’t necessarily mean that you should leave flexibility aside just to make your SDK simple and easy to use. Flexibility should also be a priority. No assumptions, ? remember With the right mix of simplicity and power, your SDK will act as the perfect medium between your users and your platform. This, in turn, will increase your adoption rate dramatically. A trivial example of this would be the process of sending a message on the Mitter platform. Currently, the upcoming SDK has four different methods of sending a message. With minimal effort, you can send a plain text message, or an image message or a file message. However, if you want to have total control over the message that you send, there’s a generic function which accepts a object which you’re free to customise as you like it. Message 3. More than just an API wrapper “Inside of every problem lies an opportunity.” — Robert Kiyosaki What good is an SDK which acts as just a thin wrapper around your APIs? Sure, it alleviates the pain of interacting with bare bone APIs but that isn’t a pretty big problem to solve. Your SDK should be more than just an interface to call APIs. It should do a lot of heavy lifting and manual labour. The goal here is to time to release a product by a significant margin. Your SDK should reflect that philosophy from all angles. cut down Identify the various pain points in your current SDK or your competitor’s SDK and solve them. Give people a reason to choose and stick to your product. For example, Mitter’s new Android SDK does , , and a lot more stuff for you switched on/off by a single line of code. token refreshing error handling Isn’t that ? convenient The road ahead “There is always space for improvement, no matter how long you’ve been in the business.” — Oscar De La Hoya Although these were a couple of core observations that I made on my switch from developing apps to developing SDKs, they are in no way a complete reference. These are just observations from working period. 2 months There’s always of room to improve. plenty Have some tips of your own? Feel free to share them down below. Also, please 👏 👏 👏 if you’ve found this article to be useful and send it to other people who might find it equally useful. This article was initially published on the Mitter.io Blog .
