How to Build a Bulletproof #SDK

Posted on June 3rd, 2016

The speaker from @Flurry emphasized four main themes on the way to making happy developers using your SDK:

Respect users (hardware, not people in this case)

Respect developers (people)

Clarify assumptions (more about developers)

Things you can’t control

Within each theme

Respect users.

Be considerate of battery life. Actions include

Limit network calls

Illuminate the screen only when necessary

Network time is expensive – keep it to a minimum by downloading once and keeping the download in memory

Phone space is limited – when you are done with the data you have downloaded, delete it.

Minimize startup time

Use techniques to keep startup time to below 2 seconds

Don’t block the main thread

If possible defer loading until after startup

Respect developers

Don’t do anything that causes the app to be rejected from the store, such as renaming system variables in iOS or using Id’s in Android that you should not reference

Don’t violate any store policies

Don’t request information that is off limits

Don’t call private APIs

Don’t put all your good ideas in a single SDK

Bloatware is not welcome (see phone space and startup time above)

It’s often better to have several small SDKs

Create slim SDKs and ones that don’t leak

Clarify assumptions

Document all your assumptions

Even better, design the API’s so developers can’t violate assumptions

If the SDK fails, complain LOUDly in the debug logs

Things you can’t control

You need to be vigilant for system changes

There is nothing you can do about them, but react quickly

There are differences between #iOS and #Android that require some modifications in the SDK. One example is in the speed of the exit from an app. Apple devices tend to have less memory, so they are more aggressive in terminating apps quickly and reclaiming memory. This is less so in Android.