Best Practices in Mobile SDK Development - by Robosoft Technologies - Medium

Best Practices in mobile SDK development | by Robosoft Technologies | Medium 2/9/21, 4:41 pm
!"#"$"%&'()*+,"-"./)$ 8765$75 E)/$+/@*/)A
!"#$%&''&()*+ ,-&./ %&''&(
0)$&'123*&/*)$'/,'4"#/-)
567'8)9)-":4),&
0&-&+&1/$2)345&'&67)+ 8)9$:#;$:<=> · "$?75$*)@A
B?@6)$C7@D
There are a lot of SDKs and re-usable components freely

available in the market. One might ask, what the gold standard
is while writing SDKs. When it comes to answering this — we
can always look up to Apple. It does a fantastic job of
introducing its new SDKs with well crafted documentation,
programming guides, and sample code for most of its SDK
https://robosoft.medium.com/best-practices-in-mobile-sdk-development-cb6316a14406 Page 1 of 13
components and frameworks. To match up to that standard, it’s

crucial that a developer takes utmost care while designing a
mobile SDK and writing APIs.
Developing iOS SDK or library refers to delivering stable and

delightful APIs, which expose the product’s features and
functionalities to the end users/developers. Besides that an
SDK also contains documents and sample codes to aid
developers on ways to use it.
As you are already aware, developing a mobile SDK is no child’s

play. But, following certain rules ensures it reaches perfection.
After working on a number of SDKs for different products we
have come to understand it better. So, herewith we have
compiled for you some of the best practices of developing an
iOS SDK.
Why
The first question you have to ask yourself is why you want to
build an SDK:
Is it because you have something to offer as a service that

multiple app developers can use?
Is it because you want to mask the users from the internal

implementation, APIs calls and the business logic of your
service?
Or is it because you need to have flexibility in terms of

compatibility, scalability and future enhancements and
don’t want others to tinker with your business logic or
service or reverse engineer?
If your answer to any of these questions is in the affirmative,

then you must build an SDK.
What
Once you have decided that you will be building an SDK, you
have to identify what are the features that you are going to
incorporate in the SDK.
Does it require a user interface or will it be without a UI?
Does it piggyback on the UI of other apps or system

frameworks
Does it require any explicit user permissions before enabling

the features?
Does it involve web view, network calls, security

considerations or any other platform device specific
features?
How
This is the phase where you decide how you are going to
develop your mobile SDK. A well designed SDK should aim to
make your life easier, however it’s a tedious process that

involves a lot of work so you can help create the best user
experience possible.
Here are some of the different aspects that you need to

consider before proceeding with developing a mobile SDK.
Simplicity
Most of the delightful frameworks, re-usable components in the

market are failing to make a name, not because of the
complexity of the work or APIs but because of the difficulty
faced by the app developers while integrating the SDK. It is
really painful when the SDK is difficult to integrate and
developers won’t grasp the features that SDK provides.
This is an automation era. In order to persuade the developer to

embrace your SDK, it’s mandatory to adapt automation in SDK
integration. This can be done through scripts, cocoa pods, and
providing Xcode template, which would download and auto
integrate with the specified target.
Once the SDK is integrated then app developer starts to look at

APIs. As an SDK developer ‘don’t invent a new wheel’ by
introducing new conventions, which are alien to developer. It’s
best to follow the standard convention, naming variables,
methods and design patterns that the app developers are
familiar with.
Tips to simplify your mobile SDK:
1. Initialisation of the SDK using your app key and secret ID

should not take more than one line.
2. Provide specific interfaces and objects into your SDK and

document them well.
3. Handle errors and exceptions within the SDK and return

statuses back to the app via callbacks or delegates.
Security
One of the most important aspect of the the SDK development

is the security aspect of the framework. When dealing with
payments it is important to understand the security related
aspects of the various APIs and ensure that no sensitive
information related to the customer’s payment instrument is
stored in any form.
Some best practices to follow here are:
1. Use SSL for all networking calls.
2. Use certificate pinning to avoid man-in-the-middle attacks

and to ensure that the SDK communicates with the right
server.
3. Avoid use of local storage of sensitive information. If you

really have to, then store it securely and in an encrypted
manner.
4. Purge all system-created web cache data and other local

data, if you have stored, when transaction is complete.
Scalability
Payment systems are always changing and new payment

instruments may have to be added to the SDK. To enable easy
addition of newer payment instruments, make the SDK
agnostic to the changes in the payment instruments in the
backend. This is possible if the SDK uses a web-based backend
since the web page can be modified to include new payment
methods without affecting the SDK. However the
communication and handshaking between the web based
interface and the SDK should be kept consistent for all payment
instruments.
Compatibility
Ensure that the SDK is compatible with the latest OS version

and architecture. Follow all guidelines enforced by new OS
releases and test the SDKs with the latest OS releases.
When you develop an SDK for the first time you will set a base
version of the OS that the SDK would support. Ensure that
future versions of the SDK also support the first version you
started with. Each client might have their own reasons to
support a particular OS. SDKs should be able to support the
clients. Do not remove support for the OSs that you have
previously supported unless absolutely necessary and once you

have confirmed that the user-base is insignificant enough to
drop support.
Coherence
Make sure that your SDK maintains the coherence of the

features that you provide. For instance if there is an API within
the payment SDK to initiate a transaction, then ensure that the
SDK supports cancellation as well. Don’t leave the developers
using your SDK hanging in the air.
Abstraction
Hide the developer as much as possible from the inner details

of the SDK. Create actual objects that are usually dealt with in a
payment transaction. At a minimum the following can be
exposed to the user.
1. Order object — Allows the user to encapsulate order details

in an object. Include all information required by the actual
Payment service provider and the information required by
the merchant for tracking the order.
2. Server configuration — Often times SDK integrators will

require some kind of staging or testing servers to test their
payment flows without actually incurring any cost. So
provide server configuration that they can instantiate
depending on their requirements. For development they
could use a staging or testing server and for production they

can use the actual payment server.
3. Transaction object — An object that encapsulates a

transaction information and status.
Logging
Provide support in the SDK to turn on logging so that the

developer can see the actual transactions happening and what
kind of payload is transferred between the app and the servers.
This will help in troubleshooting and providing support to the
users.
User Interface
If your service requires a user to login to your platform, provide

a native user interface to perform the logging in process. If it
requires a web-based interface provide appropriate delegate or
callbacks to indicate the various steps and provide the status of
the transaction.
Although you can provide your own user interface for your
service, do provide enough support to customise the native UI
to the extent that it does not degrade or hide your brand.
Storage
If your SDK requires storage, make sure that you store your
data in your own namespace or container instead of using the

application’s namespace. Take into considerations the security
related aspect of your data and ensure that sensitive
information is secure and encrypted. Use temporary folders or
cache directories for storing transient data to avoid backing up
on the cloud.
Resources
While writing SDK, especially mobile SDK, developer should be

aware of magnitude of the resources that SDK consumes. SDK
should satisfy the requirements but while maintaining
minimum resources and providing maximum functionality. In
order to provide maximum functionality following factors play
a significant role:
a. Battery: Don’t kill the users’ phone battery by doing lots of

polling or requesting frequently for resources like Location
updates etc. When in doubt, always postpone the task or
perform batch processing so that it won’t drain the users’ phone
battery. Use Instruments like ‘Energy Diagnostics’ for checking
battery consumption.
b. Network: Using network is the tricky bit. If the particular

requirement is real-time, use optimised system APIs to get the
job done, if it is not real-time, do a batch processing.
Remember, user may not always be in cellular network service
area, therefore be canny on this one. Always try to use network
payload as small as possible and use data-compression

techniques to ease the user’s network bandwidth by adopting
gzip encoding. If the SDK needs to download significant
amount of data from a server, ensure that you sufficiently warn
the user when he is on a cellular network.
c. Memory: SDK should procure allocations when seems

necessary and free up memory as soon as the job is done.
Memory leak in SDK generally receives negative feedback.
Handling low memory warnings to all classes are advisory. Run
Instruments for allocation and memory leaks, and test
rigorously.
d. Performance: It’s inferred that good design is concurred to

good performance, knowing how your SDK behaves is very
critical. Shipping SDK to developers without checking the
performance is hazardous. Profiling your SDK before shipping
SDK should be done in time. Be modest in performance tests
and run through all the timely unit tests and API usage in SDK
implementation. Your ultimate goal is to develop a mobile SDK
that does not affect the host app using your SDK.
e. Size: Make necessary but informed decisions while including

resources in
your library or SDK as this would result in increase of host app’s

App Store size. There are a lot of in-built tools that support
features like App-Thinning, Slicing and Enabling Bit code. It’s
more of a decision based requirement and one should

understand the consequences if used in the wrong way.
Custom name space for third-party sources
Try to avoid using other third party modules in your SDK as far
as possible. But if you really must use it, then, change the class
names and global variables to avoid clashes when the same
third-party modules are used by the main app.
Sample code & Documentation
The documentation is the first thing that app developer would

look into when SDK is provided to them. It is very crucial that
SDK should accompany well-written documentation which
provides a roadmap of how the SDK can be used and also gives
insight on SDK public header file. It is advised to provide
sample for API usage in the documentation. Documentation
should be considered as the selling point of your mobile SDK.
Providing interactive documentation is good but building one is

time consuming. There are lot of tools that can be used to get a
neat and interactive documentation such as DoxyGen,
AppleDocs and Jazzy. Say for example, when you use Jazzy, it
generates Objective-C and Swift documentation very similar to
that of Apple’s in just few steps.
Last but not the least; provide enough sample code to let the
developers integrate the SDK easily into their apps. Most of the
times developers just copy and paste the sample code, and
change the keys and identifiers. Ensure that some unit testing is
also included in the sample code to enable the integrators to do
their own unit testing with their own parameters.
Packaging
How you package your SDK and publish to the world also has
an important bearing on the success of your SDK. So it’s
important to pay special attention to the packaging of your SDK
for distribution.
1. Provide simple, yet complete documentation of the actual

SDK, sample code, license and read me in a well-structured
hierarchy.
2. Create CocoaPods, Carthage, static and dynamic

frameworks setup to allow people to integrate your SDK in
whichever form they want.
This article was written by Ramachandra N, Technical Architect at

Robosoft Technologies.
7F8 8(71/ G&-7')$,99$H)I)'&9?)5/ G&-7')
,-&./ J*7/) K)'9 L)6@'

Best Practices in Mobile SDK Development - by Robosoft Technologies - Medium

Uploaded by

Copyright:

Available Formats

Best Practices in Mobile SDK Development - by Robosoft Technologies - Medium

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Best Practices in Mobile SDK Development - by Robosoft Technologies - Medium

Uploaded by

Copyright:

Available Formats

Best Practices in mobile SDK development | by Robosoft Technologies | Medium 2/9/21, 4:41 pm

!"#"$"%&'()*+,"-"./)$ 8765$75 E)/$+/@*/)A

!"#$%&''&()*+ ,-&./ %&''&(

There are a lot of SDKs and re-usable components freely

components and frameworks. To match up to that standard, it’s

Developing iOS SDK or library refers to delivering stable and

As you are already aware, developing a mobile SDK is no child’s

Is it because you have something to offer as a service that

Is it because you want to mask the users from the internal

Or is it because you need to have flexibility in terms of

If your answer to any of these questions is in the affirmative,

Does it require a user interface or will it be without a UI?

Does it piggyback on the UI of other apps or system

Does it require any explicit user permissions before enabling

Does it involve web view, network calls, security

make your life easier, however it’s a tedious process that

Here are some of the different aspects that you need to

Most of the delightful frameworks, re-usable components in the

This is an automation era. In order to persuade the developer to

Once the SDK is integrated then app developer starts to look at

Tips to simplify your mobile SDK:

1. Initialisation of the SDK using your app key and secret ID

2. Provide specific interfaces and objects into your SDK and

3. Handle errors and exceptions within the SDK and return

One of the most important aspect of the the SDK development

Some best practices to follow here are:

1. Use SSL for all networking calls.

2. Use certificate pinning to avoid man-in-the-middle attacks

3. Avoid use of local storage of sensitive information. If you

4. Purge all system-created web cache data and other local

Payment systems are always changing and new payment

Ensure that the SDK is compatible with the latest OS version

previously supported unless absolutely necessary and once you

Make sure that your SDK maintains the coherence of the

Hide the developer as much as possible from the inner details

1. Order object — Allows the user to encapsulate order details

2. Server configuration — Often times SDK integrators will

could use a staging or testing server and for production they

3. Transaction object — An object that encapsulates a

Provide support in the SDK to turn on logging so that the

If your service requires a user to login to your platform, provide

data in your own namespace or container instead of using the

While writing SDK, especially mobile SDK, developer should be

a. Battery: Don’t kill the users’ phone battery by doing lots of

b. Network: Using network is the tricky bit. If the particular

payload as small as possible and use data-compression

c. Memory: SDK should procure allocations when seems

d. Performance: It’s inferred that good design is concurred to

e. Size: Make necessary but informed decisions while including

your library or SDK as this would result in increase of host app’s

more of a decision based requirement and one should

Custom name space for third-party sources

Sample code & Documentation

The documentation is the first thing that app developer would

Providing interactive documentation is good but building one is

1. Provide simple, yet complete documentation of the actual

2. Create CocoaPods, Carthage, static and dynamic

This article was written by Ramachandra N, Technical Architect at

7F8 8(71/ G&-7')$,99$H)I)'&9?)5/ G&-7')

!"#"$"%&'()+,"-"./)$ 8765$75 E)/$+/@/)A