From App Developer to SDK Developer (iOS)

Background

I got the opportunity to share about my experience when transitioning from an App Developer to SDK Developer in DANA Indonesia in one of the recent DANA’s GeekTalk: “Effective iOS Development: What Tools Do You Need?

Sucks for me, even after the multiple practices that I did before presenting, I was still nervous during the presentation.
Which kinda resulted in me speaking too fast and missing some important points 😔.

Luckily, we have this Engineering Blog, where I can kinda fix my mistakes and explain myself better than what I did during the presentation.

So, cheers to this second chance and hope I don’t miss anything else before publishing this. ✨

DANA SDK

As you all know, DANA has its standalone app called DANA (duh!) which you can get from the App Store or Play Store. But other than our app, we also have our custom-made SDK that we share with our clients so that they can use our features easily.

Why would our clients use our SDK? What do we provide for them?

Glad you asked, here are some of our SDK use cases that we provide to our clients:

• A Payment Method, either with DANA Balance, Debit card, or Credit Card
• User Binding with DANA
• QR Decoder, using a camera or decoding a string
• QR Generator can generate a QR Image or QR String
• Opening an interactive in-app browser
• And so on..

Pretty neat right? Our clients can make a mini-app by themselves just by using our SDK.

“But why should we use SDK instead of doing a direct back-end call? That way we don’t have to integrate with your SDK”

Well, you can indeed do a direct back-end Http request and process the response by yourself, but why would you? Here’s a difference between using our SDK and doing an API Call Manually with generating a QRIS (Quick Response Code Indonesian Standard) string as an example :

In this example, I simplified a few processes like “Get required QRIS data from response” into a single process for transparency purposes, even though it has a few more steps included in it.

As you can see, our SDK handled quite a few numbers of actions that our clients should’ve done into a much simpler, precise, and definite action. So, again, it is up to you which one you want to use, but I’d recommend doing the API call if you want more works laid out for you 😉.

Starting Out

I have never developed an SDK before. There’s no interface, how do I see the outputs?

If you started as an App Developer and transitions to an SDK Developer, this might be your initial concern. Compared to apps where we can see the Interface and UI.

Our SDK products are in the form of frameworks. We can’t run frameworks. So how do we test it?

There are 2 ways to test them, and I recommend doing both of them.

The first way is to create an Example App that uses your framework.

So, starting from the beginning let’s create a new project. We won’t be making a single view app though, we will make a framework like in the following picture:

I named my framework PronouncerService, to do some pronouncing stuff. You can do it in Swift, but for this example, I’ll be doing it in Objective-C

Go to the project directory, you should see that the target is in the form of a framework. Add a new target, scroll down, and select single view app as the target. and name it however you want, but make it descriptive. I name mine PronouncerServiceExample because it is an example project of my PronouncerService framework.

I created a new class called NumberCheckerService, and inside it, I have this super awesome function in my framework that can tell if a number is one or not 😏.

You need to make sure the class is set to public in Build Phases → Headers. So people can use it

Don’t forget to also import the framework on the Example Target

Now head on to your ViewController, import your framework and delegate. Create a simple UI and test to see if the code that your framework has is working properly by using the functions that your framework provides.

Congratulations! You have successfully made an SDK and tested it in the shoes of your clients!

The other way is to use unit test

If you’ve experienced doing unit tests already, it should prove easy for you. Basically, we will test all our functions and see if they work as intended using pure codes.

Unfortunately, I can’t provide you the step to step on how to unit test your SDK in this article. But if you are interested in it, drop a comment and I can try making it in future articles.

Lessons from being an SDK Developer

Here in DANA, we have 3 principles that we uphold in our day to day work as well as in the products that we deliver. And I think these 3 principles fit in quite well with the principals that we should implement in our SDK. The Principles are:

• Trusted
• Friendly
• Accessible

Trusted

Trusted implies that we deliver what we are expected to deliver. Our customers trust us to deliver a quality product, and that is what we are going to deliver to them.

That means our code must have no crashes, no bugs, and no unexpected behaviors.

How do we achieve that?

In DANA, we have what we call CI 991 for our CI process. Part of CI 991 is implementing 991 Test Criteria

The first 9 indicates a 90% build pass, which means that when we run 10 unit tests, it must succeed 9 times before it becomes acceptable.
The second 9 indicates 90% Code Coverage, which means that in the whole project, it must reach 90% Code Coverage.
The last 1 indicates that the whole unit test must be completed in less than 10 minutes of build time.

In Xcode, you can achieve this by running Unit Test (Cmd + U), switch to the Report navigator from the Project navigator, and see the code coverage and Log for these pieces of information. As shown in the picture below.

The 991 Test Criteria, Example Project (explained in the previous segment), Code Review, and QA check will help ensure that our SDK is well tested before delivering it to our merchants.

In addition, to make sure that there are no unexpected behaviors in our code, we must make sure that we will catch any exception in our methods. This is also tested using Unit Test.
First, enable code coverage by clicking the top right part in your Xcode, and click on Code Coverage to enable it as seen in the example below.

If your code is not tested yet, it will be shown in red like this:

But if your code is fully tested, and all exceptions are covered, it should show something like this:

Lastly, the merchants will lose their trust if they find any issues with your SDK, so make sure that your code is well tested before distributing them!

Friendly

To make our SDK user friendly, our users must feel comfortable using it. There are 3 points that I think would improve the friendliness of our SDK, they are:

• Language
• Design Pattern
• Code Implication

Language

Let’s start with language, as an iOS Developer, we only have 2 choices of language, Swift and Objective-C

If you’re in a rush, I would say go with your preferred language. But if it’s a long term project and you’re just starting out, you might want to think carefully before you decide your language of choice.
In DANA, we use objective-C to create our SDK because we’ve been creating our SDK before Swift was proven stable for backward compatibility.

Now, since Swift is officially ABI stable, you have the option of writing your SDK in the newest version of Swift without having to worry about your clients receiving errors for using a different version of Swift. There is a whole lot of arguments and debates out there regarding Swift vs Objective-C, so you might want to research them first before finally deciding your choice. Just put yourself in your customer’s seat and imagine which SDK would be friendlier to them, Swift or Objective-C?

Design Pattern

As an iOS SDK, for iOS Developers, we should use a Design Pattern that’s common and well-known in the iOS Environment. We can use things like the Singleton Pattern, Delegate Pattern, or anything as long as it’s familiar and will not trouble our clients

Code Implication

What does your code imply it will do?

Take a look at this function. This function implies that it will convert your value in the form of NSNumber, and return a Hex form of that value in the form of NSString. It explains everything that it will do from the name and parameters.

A code with good implication is self-explanatory and does not require our user to spend time thinking about what it does. If it says that it will convert to a Hex value, it should do just that. There shouldn’t be any processing user data in the function, there shouldn’t be any networking done in it if it doesn’t explicitly says so. It should only do what it implies to do.

Accessible

Finally, our SDK should be accessible. That means our SDK should easily be understood and used. Remember, our clients want to use our SDK because they want to save time. They want us to do the work for them. If our SDK is not accessible, why would they want to use it? Since it’s going to take a lot of work anyway.

To make our SDK accessible, we can give our code some documentation when they are needed. Ideally, our code should be able to explain itself, but if that’s not possible, we can always give some comments so our clients can better understand them.

Be careful about documentations though, not all codes need documenting, as some codes should be able to explain themselves. Be careful not to put unnecessary comments as it will create a lot of distracting noise like in this example below

We should also include documentation on our repository page. As that is what our customers first see before reading our code. Documentations in our Repository should be in the form of README and also a changelog

READMEs are a way to explain our SDK they should include the necessary steps from how to install them, until how to implement them.

While changelogs are used to describe the changes from the previous version to the newest version. So that our users will know what to change when they update to the newest version. Here’s an example of RxSwift’s changelog:

Accessing our SDK

Should you or your business be interested to integrate DANA’s SDK into your app, please reach out to DANA’s business team and we will provide the best solution for you.

Conclusion

In conclusion, our SDK should be a Trusted, Friendly, and Accessible for all our customers

And with that, you should learn all the necessary skills to become an SDK Developer! I hope this article can be a help to all you readers. Head over here should you want to join our amazing team in DANA!

Special thanks to my mentor, mas Hardian Prakasa who helped me with this article, without whom i wouldn’t have thought of this topic nor write this article 🙏