Mobile App Development has never been an easy job due to the flood of devices and customized Android OS. You may not be fully sure of your app’s working in all the possible devices that your users may be using. So Mobile App’s performance and Usability is a variable. Mobile SDK Development is even difficult of a job for it is to run in a variable environment i.e. host app. Here I am trying to brief some of the points which you should take care while developing a Mobile SDK.
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; https://www.intertech.com/Blog/android-handling-the-unexpected/)
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: http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html And here: https://docs.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-auth
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: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html And https://yossidahan.wordpress.com/2012/03/31/implementing-a-platform-for-exchanging-files-on-windows-azure/
Distribution Best Practices
Signing the SDK
- pro-guard rule file should be included in SDK.
- Put following in of defaultConfig of build.gradle (ref: http://stackoverflow.com/questions/38503434/gradle-are-proguard-configurations-inherited/38520637#38520637)
- consumerProguardFiles ‘proguard-rules.pro’
Mobile SDKs can be distributed via:
- Public jCenter repositories (https://inthecheesefactory.com/blog/how-to-upload-library-to-jcenter-maven-central-as-dependency/en)
- Public Maven Central repositories