Creating SDK is not an easy ride. Naturally, it has to be created out of sheer necessity. Next few minutes and a couple of hundreds of words will be dedicated to what it takes to create a proper SDK and when and why it should be done.

Let’s begin with a question. Why should one put in the time and effort to build a proper SDK? It’s a tricky one, especially considering an awful lot of SDK’s and reusable components already available on the market. Just like famous Apple does, providing us with a stream of masterfully produced SDK’s completed with documentation, programming guides, sample codes, etc. In other words, not only they bring great tools of the trade, but also the examples of the high standard to match. Maybe even too high for some.


So, you should make an SDK if:

  1. You have some services you can offer to mobile app developers;

  2. You want your future enhancements to be as compatible, scalable, and flexible as possible;

  3. You don’t want your API calls, business logic or service details to become anyone’s business other than yours (pun intended).

If you answered yes to more than one feature, congratulations – you need your

own SDK. Call a team meeting.

Once the decision is made, it’s time to identify the features your future SDK will possess. It will do no harm to ask yourself (or your teammates for that matter) another set of questions:

  1. Does it require UI?

  2. Does it depend on the other app(s) UI?

  3. Does it need user permission to enable any of the features?

  4. Does it involve web view, network calls, security considerations or any other specific features?

The next step is to figure out how your SDK will be developed. Remember, it should make your life easier, not harder! If it does, you’re clearly heading the wrong direction. Turn back.

Have you ever wondered why Apple’s SDKs and components are so good and why the majority of the other kits available on the market sink without a trace? The truth is, even if the API is complex and functional, most of the kits suffer from the integration problem. It can bring a tear to one’s eye when a cool SDK is difficult to integrate, or in some cases can’t be integrated at all. This problem can be eliminated through scripts, Cocoa Pods and/or providing an Xcode template.

It’s always better to stick to standard conventions and methods than try to reinvent the wheel. And fail. Here are a few tips on how you can simplify your future product:

  1. Use your app key and secret ID for initialization;

  2. Document specific interfaces and objects of your SDK;

  3. Return statuses back to the app via callbacks or delegates;

  4. Handle errors.

Another important thing that we’re going to touch upon is security. Dealing with payments and sensitive information means that everything must be safe for the customer and hidden from a stranger’s eyes. To ensure that every bit of data is sealed, you can use the following practices:

  1. Use SSL for all networking calls;

  2. Use certificate pinning to avoid attacks and commit your SDK to the right server;

3) Do not use local storage, and even if you do, encrypt the data;

4) Keep your cash data clean.

If you want to make a useful product, you should make it adaptable and susceptible to changes. When some new payment instrument of the system appears on the market, your SDK should be able to click with them. It can be made possible via the usage of web-based backend and web page modification.

Your SDK should be compatible not only with basic OS but with future versions of it as well. Remember, you are making it for someone to use, so make sure no one is left behind. Clients have their own reasons to support any OS they like. And as we all know, the client is always right.

Also, don’t leave your future client’s developers in the middle of the road to the features. For example, if your SDK supposes payments, make sure that you consider the whole lifecycle for this operation – not only API for transaction initialization, but a way to cancel it too.

The goal of an SDK creation – is to simplify the life of the user – so let’s say for payment feature you shall create all the objects the payment transaction deals with, but hide it deep enough to keep your customers focused on the right things. In this particular case you can do the following:

  1. Provide a configured server to let the developers test the payment flow without the usage of servers of a payment provider or their own servers until the customer goes to production.

  2. Give a transaction object that incapsulates transaction information and status.

  3. Give an order object, that contains all information required by the actual Payment service provider and the information required by the merchant for tracking the order.

  4. And obviously the developer shall have the possibility to see the logs for actual transactions, and transactions made in the past to have more tools and points of control for user support.

Leave a Reply