3 Important Lessons that I Learnt from Developing an Android SDK

Like Uncle Ben said, with great power comes great responsibility…

After developing Android apps for over 3 years now, I recently joined Mitter to lead the Android SDK development for the platform.

The transition from being an app developer to an SDK developer wasn’t 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.

A simple concoction of recognizing that a change in approach is needed and the willingness to act on that thought, did the trick.

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 daunting a platform looks from the outside, an SDK should make the process of interacting with the platform, a walk in the park.

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 reducing friction by providing simple set-up, and lots of handy functions to get the job done, get the ball rolling.

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 Message object which you’re free to customise as you like it.

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 cut down time to release a product by a significant margin. Your SDK should reflect that philosophy from all angles.

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 token refreshing, error handling, and a lot more stuff for you switched on/off by a single line of code.

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 2 months working period.

There’s always plenty of room to improve.

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.