SDK Development Stories: Interviews With Our Developers

Mobile apps have become an integral part of our daily lives and have now become an incredibly lucrative and productive market. However, this very quick pace of mobile app development would not be possible without a quickly evolving set of mobile app development tools to help them along the way.

Today, we will take a look at what it is like to work on one of the most ubiquitous and important types of tools that mobile app developers use: SDKs. Here is what our developers had to say about SDK development and how it differs from mobile app development

‍

Yousef Hamza - iOS team

‍

‍

Can you give us a quick run-through of your development experience?

YH: In college, I tried my hand at a few different things until I managed to find an opportunity as a summer intern on a Google-sponsored open-source medical records app. The project I worked on was for iOS and that was my first experience developing for iOS. I tried my hand at a backend development internship with a local start-up for a few weeks but I was not as happy with it as my iOS experience.

‍

What made you get into SDK development?

YH: Well, it honestly was all coincidence. After I graduated, I was not decided on what path I want to take. I was looking around into the opportunities out there, but I wasn’t really set on SDK development or even iOS for that matter.

Then one day, I got a call from Instabug to interview for a position on the iOS team, and with my positive experience with iOS previously it all kind of clicked. I’m thrilled with how all of that turned out; I think it worked better than if I had planned it.

‍

How is SDK development different from developing apps?

YH: The first and probably biggest difference is I don’t feel we get the same level of support from Apple as an app developer gets. It is, of course, understandable and they're not alone in doing that but that still has some pretty big implications.

As an SDK developer, you have to accept that there will be a lot of Apple features and tools that you will have to either implement manually or find third-party tools to help you. When you’re developing an app you get first-class support, when you see a new feature at WWDC you know they had you in mind creating it. For example, interoperability between Objective-C and Swift is still not as straightforward as it is for Applications. Another example is setting up screens and the flow between them is a relatively simple matter for an app developer, but for us, we have to basically build the whole UI view from scratch, creating containers and worrying about where they will appear and what they will look like. It’s just not as straightforward.

‍

How does developing an iOS SDK differ from other platforms?

YH: Well, most of what I mentioned in my previous answer applies here, but there’s also the excellent state of testing on Apple’s platforms. They introduced a bunch of testing utilities in XCode a few years ago and kept improving on them, and now they make testing on iOS so much easier. Apple also makes it very easy to support a variety of different devices, with different sizes and hardware.

As long as you work within the limitations Apple has set, developing an iOS SDK is mostly a pleasure.

‍

What do you like and dislike about SDK development?

YH: We deal with a lot of data at Instabug. This might not be specific to SDK development, but SDKs tend to deal with more data than apps do. For me, working with this large volume of data and figuring out how to process, send, and store it efficiently and securely is much more exciting work than creating UI views. It’s just much more of an engineering challenge.

One of my major dislikes about developing an SDK for the Apple platform is how many of Apple’s latest and greatest features are not available to us for usually around a year. There is a delay in support for most of these features when it comes to frameworks. Even then, it’s not straightforward and you end up having to figure out a few workarounds.

‍

Do you have any advice for someone who just started working on an SDK?

YH: As an SDK, you have to develop a different mindset and attitude than if you were developing a regular app. You can’t just move fast and break things if those things do not belong to you.

Your SDK is a guest in your user’s app, and as a good guest, you should be respectful. Don’t assume anything about your host app and don’t reinvent the wheel; your SDK should feel like part of the app. Always keep in mind that you share all your resources with your host app and be mindful of what you consume, and above all, don’t interfere with its behavior and never cause it to crash.

On the technical side, I would say, if at all possible, open-source your SDK. At Instabug, we publish our SDK as a binary framework because it contains a lot of proprietary information, but if you don’t have that issue, going open source will circumvent a lot of issues you may face later.

Another thing is if you don’t already have a demo app that can properly show off your SDK’s capabilities you should work on one as soon as possible. You have to go further than a basic demo app that shows the basic functionality of your SDK. Your demo app should be able to demonstrate the full potential of your SDK quickly and easily.

And finally, you have to do extensive testing and take full advantage of XCode’s unit testing and UI testing tools.

‍

Mohammed Zakaria - Android team lead

‍

‍

Can you give us a quick run-through of your development experience?

MZ: I have mainly worked on Android development at a few different companies since I graduated, as well as a lot of freelance work. I do like to tinker with other technologies and frameworks, however, and I have some experience with things like Django, Laravel, Flutter, and even iOS for a brief spell.

‍

What was your first experience with SDK development?

MZ: Well, my first experience was with a small library that I built to make my freelance work easier. One of the things that I had to implement in a lot of the apps I worked on was a gallery, so I developed a small and lightweight library with all the basic gallery functionality and open-sourced it. It’s up on GitHub and I sometimes get messages from people using it to this day.

‍

What made you decide to turn it into SDK development professionally?

MZ: It was all a coincidence really. Even when I joined Instabug, I had expected it to be a new challenge that I could learn from and then move on after a year or two. But with time, I found that the experience of developing an SDK offers much more of a challenge than developing an app. As an app developer, most of the challenges you will face will have many possible solutions and it’s just a matter of integrating a library or even writing code to solve it. But for SDK developers, there are a lot of limitations; from size to compatibility to security to performance, you have to consider every single angle for every decision you make.

‍

How is SDK development different from developing apps?

MZ: SDK development needs an entirely different approach and mindset. You will face a different set of challenges and a lot more limitations than app developers. You can’t use libraries most of the time so you will have to code it yourself and when you write that code you have to worry about its compatibility with older versions, size, security, performance, storage, threading, and memory 10 times more than app developer should.

This pushes you to understand the inner workings of your favorite libraries and their features because most of the time you will have to develop your version of them to use in your SDK.

You also have to be extremely detail-oriented because your SDK is going to be used in many different ways and for many use cases you never imagined.

Another big difference is the sheer amount of devices our SDK runs on. Very successful apps may be running on a few million devices, but a moderately successful SDK can run on a couple of billion devices. And on Android, that’s a huge variety of devices and environments which ideally, you should be able to support. I mean, we once had a user who was trying to run our SDK on a microwave oven!

‍

How does developing an Android SDK differ from other platforms?

MZ: It all falls under the extreme fragmentation of the Android ecosystem. You never know what kind of devices and Android adaptions you will have to deal with. You will have to be able to run not only on devices with very low specs but also on some very unexpected ones. We once had our app running on a tablet that didn’t have a wi-fi module but had a LAN port instead.

We have to always take that into account with every feature we work on and we can’t take anything for granted. You have to expect the unexpected and be ready to handle it, and that can be annoying sometimes.

‍

What do you like and dislike about SDK development?

MZ: What I like most about SDK development is that I’m always learning new things. Throughout the experience, you will have to work on many support tickets, talk to your users, and write your own version of the libraries you need. That will teach you a lot of things that you can only learn by experience.

Although I like the challenge of not being able to use libraries, it can also be a pain, to be honest. We can’t use all the new support libraries available for Android for instance. Well, we can use them but it’s usually not straightforward and includes a bunch of workarounds. You can’t just decide to integrate a library to try it out and see how it works for you inside of a day.

Working on an SDK can also be quite stressful sometimes. Bugs are a much bigger deal for an SDK developer so there is a lot of pressure to prevent any bugs in production and when a bug does appear the pressure doubles to fix it as soon as possible. But you will also learn a lot in the process and even learn to deal with the pressure.

‍

Does it not bother you that most of the code you write doesn’t translate into something you can see?

MZ: I don’t really feel that way. I see my code when I watch a user’s app store rating improve after they integrate Instabug and their app store reviews start to be positive. And it feels good to know that my code is running on billions of devices from low-end to high-end and everything in between. The only downside is that even after four years at Instabug, I still can’t explain what I do to my parents or most ordinary people but I’ve gotten used to that.

‍

Do you have any advice for someone who just started working on an SDK?

MZ: Always try to understand how SDKs and libraries work from the inside because at some point you will need to use their features in your SDK. This will teach you a lot of things and give you a lot of ideas about how to improve your code. It will also help you adopt a different mindset and approach to development which you will need if you want to be a good SDK developer.

‍

Ali Abdelfattah - cross-platform team lead

‍

‍

Can you give us a quick run-through of your development experience?

AA: I’ve been fascinated by programming since I was in high school so even though I majored in an unrelated field I picked it up as a hobby. I’ve had a lot of experience developing cross-platform apps as part of a software house. We worked on many apps for well-known companies in different industries. I’ve also had some experience with front-end development and web development in general and .NET frameworks.

‍

What made you get into SDK development?

AA: My first experience with SDK development was when I joined Instabug as a part of the front-end team. Although I didn’t directly work on the SDK at that time, I worked on the Instabug dashboard and had a lot of time to understand how the SDK works.

Then recently our cross-platform had an opening and I felt that, with my experience, I can really be of help there. Plus I’ve always been interested in cross-platform development, so I decided to make the switch.

‍

How is SDK development different from developing apps?

AA: So far, working on Instabug’s cross-platform SDKs has been a thrilling experience. With all the different cross-platform technologies we support and the rate at which they are updated, there is always something new to learn. Obviously, that also has its implications on our development decisions and it can be a pain sometimes, but there’s never a dull day.

The biggest difference I feel is with the update cycles. Web developers can fix a bug and release the fix right away, app developers have to release a new version with the fix and wait for users to update to the latest version. SDK developers have to release a new version, wait for their users to update to the latest version, and then wait for their users to update to the latest version.

This is very tedious, to say the least, and makes it very important for us to make sure that whatever feature we release will work as intended in all different scenarios and environments.

We’re trying to support a ton of different technologies which obviously has its impact on your development decisions.

‍

How does developing an Android SDK differ from native platforms?

AA: One thing that is specific to cross-platform, is how it makes you dig deeper into how different platforms go about implementing their frameworks. When you’re writing code that is going to be used on multiple platforms, you need a good understanding, not only of the cross-platform technology you are working with but also of the inner workings of the platforms it will be rendered on.

‍

What do you like and dislike about SDK development?

AA: Developing a cross-platform SDK gives me the opportunity to keep up and work with all the new technologies coming out every day. This also makes it feel like you’re working on several different projects and breaks the monotony of working on just one major project all the time.

On the other hand, I miss working with the UI. As a cross-platform SDK developer, we rarely get to work directly with the UI. Although we don’t deal with a lot of UI in our SDK in general, the native SDK teams still do considerably more work on the UI than we do in cross-platform.

But at the same time, I do enjoy the focus that we give to the logic behind our SDK and all the behind-the-scenes work that we do. I like knowing that behind all the SDK’s seemingly simple actions visible to the user there is a whole lot of complexity that they don’t see.

Finally, unlike our native SDKs, our cross-platform SDKs are mostly open-source which gives us a great chance to have more interaction with the developer community. This is my first experience working on an open-source project and so far it had been a very positive one. I just really enjoyed communicating with them and hearing their feedback.

‍

Do you have any advice for someone who just started working on an SDK?

AA: The best advice I can give is to adopt a beginner's mindset. No matter how much experience you have with software development, there's always room to learn new things and grow.