When I started at Zello in 2016, my first project was to improve our (now legacy) Android SDK. Eight years later, we have just put the finishing touches on a completely new Zello Mobile SDK that my team built from scratch. I wanted to share the journey of building a better SDK from the developer’s perspective, including how the Zello team thinks about solving problems and why we decided to build something new.
When I started working on the legacy SDK, I was a recent college graduate with about a year of iOS development experience, so the opportunity to learn Android development was exciting. Our legacy Android SDK works by sending broadcasts between the host application and the Zello application, which means that both applications must be on the user’s device for this SDK to function. Coming from the iOS world, I had no idea this was even possible!
When we started talking about building a new SDK in February 2024, the idea was for us to embed it directly into the host application, and for it to work on Android, iOS, and React Native. We identified three technical approaches to achieve this:
Our team had a strong interest in option 1. It effectively guaranteed that an SDK would be possible, as there’s nothing standing in our way except time. A fresh slate meant we could benefit from our 12 years of development to produce something great. However, once we started discussing the timeline to completion, we realized this wasn’t feasible. When we built our new desktop app, it took about 6 months for the minimum viable product (MVP) to go to market, but about 2 years before it had reasonable parity with the mobile applications. We didn’t have the luxury of time, so we scrapped the idea.
We moved to option 2. These explorations mostly fell on my plate, as I had some experience with the Channel API, which we built in 2018 at a company hackathon. At its core, the Channel API allows a client to connect to a WebSocket server with a friendly API, and that server essentially acts as proxy between the client and our actual backend, which relies on a custom protocol directly via TCP sockets. We separated this into multiple categories for exploration: multiplexing, SSO, background work, push notifications, CPU usage, and memory usage. By far, the most challenging aspect of this solution was going to be for push notifications and background work on iOS. Eventually, we realized we would need some complicated system where this proxy WebSocket server is in charge of sending push notifications. While not impossible, this was enough trouble to lead us to explore option 3.
Option 3 was dreaded almost universally. What does it even mean to take an existing application and turn it into an SDK? Especially on iOS, how do you even accomplish that? Most of our meetings to discuss this option ended with even more questions, and none of us could really give any compelling answers. However, the one positive we agreed on was that if we took a couple of weeks to fully dive into this option, we’d be able to understand if it was even feasible.
So, that’s what we did. With a team of two Android engineers, two iOS engineers, and me, we cleared our calendars the last week of March 2024, and started exploring. We agreed early on that regardless of the technical approach, we needed a way to both test the SDK and demonstrate the capabilities to our customers. I spent the week creating example applications for iOS and Android, which at the time used a mocked SDK, since obviously the real thing wasn’t ready. I decided to build these with SwiftUI and Jetpack Compose, the former of which I had never used before.
At the end of the week, we had compiling frameworks for iOS and Android. Both crashed on launch, but at least they compiled! Sparing the gory details, the high level approach can be boiled down to this picture:
We left that week feeling positive about our results. We obviously had a ton of work ahead of us, but we knew this approach could work. However, it was not without drawbacks. Much of the “shared code” was tied to the lifecycle of the app, and as such the SDK needed to be initialized with the host apps lifecycle. This is unlike most SDK’s where you can load the SDK on demand. Additionally, the headless SDK was very heavy — 20 MB for Android and a staggering 280 MB on iOS. Despite those tradeoffs, which we all agreed we could improve over time, we decided to move forward with this headless approach.
Within another week or two, we had our proof of concept. We ripped out the mocked SDK from the example applications and replaced it with the SDK frameworks. This was a major milestone, and to hit it after only a few weeks of starting this option was a testament to the team’s hard work.
Another challenge we faced is that many of our customers who had requested an SDK use React Native. We’ve never used React Native at Zello, and most of us had no idea where to even begin in making our SDK compatible with it. We decided to postpone this until we had a better idea of how the SDK interface would take shape.
A few weeks later, in late April, we had a company-wide Discovery Week: a Zello tradition where we clear schedules and try to build something of value in just five days. You present what you’ve done at the end of the week, and the company votes for their favorite project
Another SDK developer, Jim, and I decided to focus on making the SDK compatible with React Native. This was truly a learning experience for us both, but we ended up with a working prototype after that week, and we won Discovery Week!
Over the course of the summer, we focused on adding new functionality to the SDK, as well as preparing our documentation so that developers implementing our SDK would know how to use it.
In September, around six months after we started the headless approach, we released version 1.0 of our SDK. This was a truly team effort, and by far one of the hardest projects I’ve had to work on here. It has shown me what our talented team can accomplish when we focus and work together. I can already see our efforts paying off — we have several clients who have implemented our SDK and I’m excited to continue working with them to bring the power of Zello to other applications.
If you are interested in checking out our SDK, please visit https://sdk.zello.com.