Mobile SDK Development Best Practices (practical notes)

Development Best Practices

You must provide native libraries for the platforms which:

  • Use almost no storage space on the device
  • Use almost no resources (CPU, GPU, RAM) of the device
  • Use no intrusive permissions
  • Do not eat up on the count of available methods (e.g. method limit in Android). The Dalvik Executable(DEX) specification limits the total number of methods that can be referenced within a single DEX file to 65,536.
  • Do not crash host App in any circumstance.
  • Have appropriate logs exposed which can help identify run time issues
  • Is able to classify between host App & SDK issues
  • Is able to scale with vast variety of Device Densities (if there is a UI component in the SDK)
  • Do almost no operation on UI thread
  • Is not a security threat to the host App.
  • Has almost no 3rd party library dependencies
  • Is tested on vast variety of OS versions (especially the older ones and the newest ones) along with vast variety of device manufacturers
  • Prevent crashes of host app (Use UncaughtExceptionHandler for this;

Data Security Best Practicies

API key: API key is generally given to app developers to authorize the requests made to the sdk. This is good way to analyze sdk usage by particular app as well. However API keys are not safe enough because anyone can capture it over the wire and bombard the sdk with unsecure requests.

AWS Sig V4 or similar: AWS (and other cloud providers) provides signature mechanism which allows each request to authenticate itself before hitting the underlying business logic. See more details here: And here:

Short lived urls: Most cloud service providers provide short lived urls for their CDN. These are good ways to secure your endpoints from DOS attacks as you can decide the life span of such urls. Check our more here: And

Distribution Best Practices

Signing the SDK

Android (Proguard):

Mobile SDKs can be distributed via:

Wheat – Mobile Functional Test Automation using RedwoodHQ & Appium

How many of you have done mobile functional test automation? I am sure many.

How many of you have done it by handwritten code? I am sure many.

How many of you have faced a need of ability to manage & reuse the test cases in a much better and brainless way? I am sure many.

How many of you have used a test management tool with a test automation tool to achieve this? I am sure only a few (I actually searched very vast on Google to get a reference before starting this project, however not even a single line of code was shared anywhere).

Here comes Wheat; a bridge between Appium & RedwoodHQ. Wheat allows you to create & reuse your test cases in RedwoodHQ in more usable way (drag-and-drop) and have them getting executed in mobile emulators or devices via Appium. Continue reading