Mobile SDKs — Challenges

Mobile applications serve various use cases for end users ranging from social media services to vacation home bookings. This ever increasing application eco system has a dependency on platforms like Android and iOS.

Although the base platform functionality is provided by Apple and Google there are many other features, like Security for example, that these platforms does not provide out of the box. As such, to fill this gap the applications depend on a 3rd party libraries.

This article covers the challenges faced by such third party library providers while providing SDK. Many of these challenges can be countered with a set of design guidelines. Those guidelines will be presented in the next article.

These third party library providers (hereafter referred as SDK Providers) typically provide an SDK (Software Development Kit) that exposes their functionality in the form of an API (Application Programming Interface). The design and development of these SDKs are complex in nature and require quite a lot of considerations.

The below figure outlines the typical architecture of a mobile application.

As the above picture depicts, an SDK sits below the Application UI and along with the Application business logic. This requirement comes with the following challenges.

Challenge 1: Integration issues.

Providing an API for customers to use is easier part of the challenge. However, designing this API to handle the requirements of customers is complex. Depending on the usecase of the application the API can vary from a simple call to Initialize the SDK to continuous interaction with the SDK while executing application’s core business logic.

Considering initialization API, let us say, an SDK requires a Configuration file to initialize. This configuration file can be read by the SDK as an argument in initialization API(as a reference to a resource). This would add a maintenance dependency on SDK for Application developers. Every time there is a change in this configuration, the Application developer needs to update with this configuration file. Any inadvertent mistakes during that process will fail the initialization of the SDK causing a maintenance issue. If there is no reliable way to identify this problem (for various possible code paths in the SDK depending on the configuration) then that becomes a much bigger issue.

Another scenario where the API usage creates integration issues is the location where the SDK API needs to be called. Depending on the use case of the SDK and the use case of the Application, a number of issues could be introduced.

For example,

Is the API allowed to be used during application initialization?

Does it introduce performance overhead?

Can it be called from main thread?

Can it be called multiple times from various entry points into the SDK?

Can another SDK residing in the application make that call?

Can another SDK and the application share the SDK calls?

Clearly defining where the API needs to be placed is quite a challenge considering all the above questions.

Challenge 2: Build issues.

This depends on size of the interface provided and the changes needed by the Application for integrating the SDK. Most of the issues faced by Application developers can be easily validated in a QA environment. However, depending on the size and nature of the Application coupled with the platform dependencies, there could be various challenges here.

For example, Google constantly updates the gradle plugin and does not provide for a reliable way to integrate third party SDKs. Android gradle plugin introduces various nuances release after release making it difficult for the SDK providers to keep up. Further, the new tools like R8 and D8 brings more complexity. Ensuring that the SDK binaries are not included while applying those tools on the SDK is a complex problem. These problems magnify with various versions of Gradle plugin and its users. Further, Obfuscating the SDK itself with a different tool will add more complexity to this whole process.

When it comes to Build Issues these are the most asked questions.

Can the SDK be used without any new changes?

Will it break any existing functionality with respect to build?

Is it compatible to latest Xcode/Android Gradle Plugins?

What will be the final APK/IPA size because of the SDK?

Will there be build issues in release mode versus debug mode?

Does SDK support bitcode?

What is the minimum SDK Version for the library(In case of Android)?

Challenge 3: Testing issues.

Most of the challenges in this scenario are mitigated if the API design and the process to test the integration have been well documented. However, there is a possibility for false positives if the documentation has issues or does not fully handle the Application constraints. Depending on the application scenario there could also be a problem that does not necessarily manifest during integration phase.

One such scenario happens, when the application has multiple entry points into it. In this case, it becomes really difficult to test all possible situations that could happen because of an SDK usage. If such issue is found during Appplication QA then is is easier to manage. However, if the issue is a corner case and happens only in field then SDK providers will have a tough time resolving it in the Application Environment.

Challenge 4: Runtime issues.

This challenge borders closely with the above Challenge. However, the cost of these issues is usually high as it involves end users of the application. Being an SDK provider and getting traced in the application crash will be a high priority issue that the SDK provider needs to resolve without having any visibility into the application architecture. Resolving such issues involves countless calls to understand the scenario where the issue happens and gather more evidence. In order to fix it correctly it becomes imperative that the application developer has to create an application to reproduce it. If the issue is not reproducible directly then adding logs to the Application and publishing an app with these logs will increase the turnaround time for these issues.

If the issue is a performance issue because the SDK is using the main thread (on Android or iOS) it has direct impact on the end user experience. In most cases this results in negative Play/App store rating of the Application.

Some of most harmful runtime issues occur because of Native Library crashes. These crashes occur in the field and are not easy to capture. They directly impact the end user’s satisfaction in using the application. Fragmentation on Android side makes it more difficult to actually see the issue on application developers side because of hardware needs.

Some questions that get asked in this case are

Has the SDK been tested on scale?

Is it Robust enough to not cause crashes because of it?

Will the SDK cause any initialization issues?

Are there any performance concerns using the SDK?

How much CPU, Memory and Network does the SDK use?

Will the SDK drain the battery?

Challenge 5: Product Efficacy issues.

These are internal to the SDK providers and the Application developers will not have a visibility into these. This makes the job of SDK providers much complex and creates a complex architectural constraint. This problem can usually be solved using Analytics. However, the infrastructure required to handle the incoming data would be humongous. Ballpark estimates of servers required to handle such load from multiple customers would put the costs in the order of millions of dollars. Having a good design and architecture to handle this need efficiently can mitigate the challenge.

Challenge 6: Platform Constraints

Ensuring parity between the platforms for the same functionality is difficult. This is primarily because of various architectural differences in the way iOS and Android have been designed.

Both Android and iOS Platforms have their own limitations on how various functionality is provided. iOS has robust multi threading support, where as on Android the application developer needs to handle it on his own. This has much more challenging dependency on the SDK provider as the resources that the SDK consumes for it’s business logic will now become part of the application. Some of the questions that get asked for these issues are

Is there a parity between Android and iOS APIs of the SDK?

Will the API call result in an ANR on Android side?

Is there a privacy concern with the SDK?

Will the play store/app store object for any improper use of the SDK?

Challenge 7: Maintenance and Enhancement Constraints

Many Application developers does not like to update the third party SDKs often. This is because they do not want to introduce another “integrate -> build -> test -> deploy” cycle that could potentially be blocking their release if the new SDK introduces a critical bug. Further, if a new API is introduced and an existing API is deprecated it warrants a change in the way the SDK is used and is quite expensive for many application developers.

The above challenges, though appearing obvious, are critical business drivers for SDK Vendors. In the next article I will cover design guidelines that will help minimize the friction while providing an SDK.